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ABSTRACT 

This  thesis  describes  and  tests  a  system  for  Low  Cost  Graphics  (LO-CO-GRAF) 
which  enables  a  small  computer  to  generate  and  display  high  quality  cartographic  maps 
from  a  remote  mainframe  computer  database.  A  small  computer  must  emulate  a 
graphics  terminal  while  interfacing  with  a  mainframe  program  which  processes  the  nec¬ 
essary  data.  This  solution  has  been  accomplished  through  four  smaller  tasks. 

The  tasks  include  communicating  with  the  source  system,  emulating  a  graphics  ter¬ 
minal,  interfacing  with  a  map  generation  program,  and  producing  a  local  hardcopy  of 
the  generated  map.  All  software  and  hardware  required  for  these  component  parts,  in 
addition  to  the  use  of  standard  methodologies,  were  selected  for  their  widespread  avail¬ 
ability  at  Department  of  Defense  (DOD)  agencies. 

Research  was  conducted  using  the  Heath/Zenith  Z-120  as  the  small  microcomputer 
and  the  Tektronix  4010  graphics  terminal  was  chosen  to  model  and  emulate;  two  sepa¬ 
rate  source  graphics  packages  were  used  to  generate  maps.  Concept  validation  involved 
the  use  of  DISSPLA,  the  primary  graphics  package  used  on  an  IBM  3033  mainframe 
computer  at  the  Naval  Postgraduate  School,  and  the  Briefing  Aid  System,  a  map  gen¬ 
eration  program  maintained  on  the  VAX  mainframe  computer  at  University  of  Southern 
California's  Information  Systems  Institute,  wrhich  was  accessed  and  employed  via  De¬ 
fense  Data  Network  (DDN). 

Specific  "how-to"  instructions  were  developed  for  application  to  the  Heath/Zenith 
Z-100  series  microcomputer.  These  instructions,  which  arc  provided  as  Appendices,  in¬ 
clude  programs  which  cause  the  Z-100  microcomputer  to  emulate  a  Tektronix  4010 
graphics  terminal,  provide  microcomputer  to  mainframe  computer  communications  us¬ 
ing  KERMIT,  present  interactive  DISSPLA  map  generation  programs,  and  explain  how 
to  access  the  Briefing  Aid  System  map  generation  program  via  the  DDN. 
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The  reader  is  cautioned  that  computer  programs  developed  in  this  research  may  not 
have  been  exercised  for  all  cases  of  interest.  While  every  effort  has  been  made,  within  the 
time  available,  to  ensure  that  the  programs  are  free  of  computational  and  logic  errors, 
they  cannot  be  considered  validated.  Any  application  of  these  programs  without  addi¬ 
tional  verification  is  at  the  risk  of  the  user. 
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I.  INTRODUCTION  AND  BACKGROUND 

Effective  Command  and  Control  (C2)  relies  heavily  on  accurate  maps  and  charts 
that  are  readily  obtainable  with  minimum  delay.  While  pure  command  post  exercises 
of  hypothetical  scenarios  may  not  be  adversely  affected  by  inaccurate,  incomplete,  or 
artificial  cartographic  products,  any  actual  movement  of  men  and/or  equipment  requires 
that  the  commander  and  his  staff  have  timely  access  to  comprehensive  and  up-to-date 
maps.  This  requirement  prevails  throughout  each  step  of  any  exercise,  planned  maneu¬ 
ver  or  crisis  management  situation  [Ref.  1;  p.  3-80].  A  commander  who  ignores  his  map 
requirements  during  the  concept  phase  of  operations  is  sure  to  fail.  Maps  and  charts 
are  essential  tools  for  those  in  charge  of  staffing  and  planning.  General  George  S. 
Patton,  who  will  always  rank  as  one  of  the  Army's  and  our  nation's  greatest  warriors, 
stated  the  importance  of  maps  very  simply  in  his  biography. 

A  study  of  the  map  wUl  indicate  where  critical  situations  exist  or  are  apt  to  develop, 
and  so  indicate  where  the  commander  should  be  [Ref.  2]. 

Perhaps  the  need  for  maps  is  most  critical  in  the  execution  phase:  the  success  of  even  the 
simplest  operation  hinges  directly  on  the  reliability  and  availability  of  accurate  maps  and 
charts.  To  put  it  simply,  timely  access  to  maps  and  charts  is  an  indispensable  C2  tool 
and  must  be  available  at  all  levels  of  command  during  all  phases  of  the  C2  process  [Ref 
1:  p.  3-82). 

The  usual  procedure  for  obtaining  maps  in  the  Department  of  Defense  (DOD)  is  to 
request  them  from  the  Defense  Mapping  Agency  (DMA)  or  one  of  the  affiliated  military 
distributing  commands.  This  requires  intricate  preplanning  for  anticipated  future  needs, 
as  well  as  a  long  lead  time  of  anywhere  from  a  few  weeks  to  several  months  due  to  the 
logistics  involved  in  physically  locating,  obtaining,  and  delivering  the  desired  maps  and 
charts.  To  expedite  this  process,  the  DMA  has  digitized  most  critical  world  areas  so  that 
the  cartographic  information  can  be  transmitted  electronically.  This  innovation,  while 
an  important  first  step  in  providing  accurate  and  timely  map  data,  is  somewhat  limited 
in  its  present  configuration  because  only  specially  dedicated  computers  and  network 
systems  can  access  the  information.  However,  this  information  is  available  on  many 
mainframe  computers  and  accessible  through  resident  graphics  packages. i  Indeed,  many 

1  For  e.xample,  the  Naval  Postgraduate  School  (NPS)  uses  the  Display  Integrated  Software 
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of  the  large  screen  displays  currently  used  in  C2  centers  for  contingency  planning  and 
for  the  World  Wide  Military  Command  and  Control  System  (WWMCCS)  displays  are 
of  inferior  cartographic  resolution.  Most  importantly,  the  DISSPLA  software  allows 
anyone  operating  a  NPS  graphics  workstation  to  generate  the  exact  cartographic 
projection  desired.  The  significance  of  generating  detailed  cartographic  products  by 
DISSPLA,  is  that  most  organizations  also  have  a  similar,  unrealized  capability  to  have 
this  type  of  small  scale,  large  area  mapping  program,  which  can  provide  them  almost 
instantly  with  the  maps  and  charts  they  require. 

A.  GRAPHICS  IN  THE  MILITARY  ENVIRONMENT 

This  thesis  is  specifically  directed  towards  the  creation  of  maps  and  charts,  which 
usually  represent  the  highest  level  of  capability  available  in  grapliics  packages.  The  dif¬ 
ficulty  to  generate  maps  involves  translating  a  three-dimensional  data  set  generated  by 
the  curvature  of  the  earth  into  two-dimensional  projections  that  can  be  printed  as  maps. 
The  need  for  accurate  maps  and  charts  has  already  been  mentioned  in  general  but  the 
following  specific  applications  serve  to  better  illustrate  this  requirement. 

1.  Command  and  Control  (C2) 
a.  Pre-planned 

Maps  are  always  needed  when  forces  are  being  employed  or  deployed.  C2 
is  exercised2  via  Command,  Control,  and  Communications  (C3)  systems;  the  commander 
and  his  subordinates  must  be  "working  from  the  same  sheet  of  music".  The  exchange 
of  information  necessary  to  achieve  a  successful  mission  is  critical,  and  usually  very 
susceptible  to  error.  To  relay  his  C2  decisions,  the  commander  could  prepare  an  inter¬ 
active  computer  menu  program3  which  could  be  made  available  to  other  commands, 
making  clear  the  decision.  The  maps  with  overlayed  or  imbedded  information  could  be 
either  electronically  transmitted  or  simply  made  accessible  to  others.  This  delicate  C3 
problem  is  resolved  with  a  C4  (add  "Computers"  to  C3)  solution.  Figure  1  illustrates  the 
dissemination  of  a  map  presentation  from  the  commander  and  his  staff  to  other  elements 

System  and  Plotting  Language  (DISSPLA)  graphics  software  program  which  contains  a  map  gen¬ 
eration  option  called  World  Coast  Utilities.  Although  this  program  is  independent  of  the  DNIA 
database,  and  therefore  does  not  reflect  the  continuous  DMA  updating  of  maps  and  charts,  it  can 
generate  high  resolution  products  that  are  amply  sufficient  for  the  strategic  and  operational/theater 
levels  of  military  planning  and  execution. 

2  C3  is  sometimes  referred  to  as  'the  reins  of  command",  that  is  the  commander's  ability  to 
maintain  control  of  the  situation. 

3  Similar  in  concept  to  the  program  provided  in  Appendix  A  in  that  different  options  or  bases 
for  decision  can  be  provided  electronically. 


Figure  1.  Use  of  Digitized  Maps  in  Normal  Operations:  Distribution  of 
commander's  intentions,  EOOB,  admin;log  information,  and  C3  proc¬ 
esses  of  the  C2  functions  through  Local  Area  Networks  (LAN),  Defense 
Data  Network  (DDN),  or  telephone  quality  communications  lines. 

in  his  chain  of  command.  With  this  map  distribution  tool,  the  commander  can  provide 
timely  progress  reports  to  his  superiors,  advise  and  inform  adjacent  commanders  of  his 
intentions,  and  effect  swift,  unambiguous  C2  direction  to  subordinate  command  ech¬ 
elons. 

b.  Emergency! contingency! crisis  situations 

Similar  to  the  preplanned,  deliberate  scenarios,  a  commander's  effectiveness 
in  a  crisis  situation  can  also  benefit  from  a  C4  application  of  digitized  mapping.  Speed 
and  accuracy  of  information  transmission  is  possibly  even  more  critical  during  an  cmer- 
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gency  or  crisis  because  decisions  are  being  made  and  forces  deployed  with  all  possible 
speed.  A  precise  display  offerees  and  enemy  order  of  battle  from  his  superior's  com¬ 
puter  could  prove  invaluable  to  the  on-scene  commander.  Additionally,  weather  and 
other  displays  could  be  made  instantly  available  to  him. 

Most  contingency  operations  usually  are  directed  from  a  major  command 
center.  The  personnel  handling  these  emergencies  are  usually  referred  to  as  a  Crisis 
Action  Team  (CAT)  or  a  Crisis  Management  Team  (CMT).  Their  composition  is  made 
up  of  operators  and  specialists  in  communications,  logistics,  intelligence,  and  other 
warfare  and  combat  support  occupations.  Figure  2  demonstrates  how  the  on-scene 
commander  and  the  CAT  or  C.MT  can  access  tactical  maps  requiring  only  communi¬ 
cations  to  some  remote  mainframe  computer.  Figure  2  also  demonstrates  another  ad¬ 
vantage  of  digitized  maps;  the  graphic  link  between  the  on-scene  commander  and  the 
Crisis  Management  Team  which  reciprocally  would  provide  up  to  the  minute  decisions, 
results,  and  options. 

2.  War  gaming 

a.  Laboratory 

C3  is  usually  ignored  and  not  normally  a  determinant  in  laboratory 
wargaming  exercises.  However,  the  highly  specialized  systems  employed  to  generate 
terrain  and  similar  cartographic  displays  are  available  only  at  major  commands  and  in¬ 
stallations,  limiting  their  usefulness  to  a  small,  elite  minority.  Using  digitized  maps, 
many  wargaming  systems  could  become  available  at  lower  level  commands.  With  the 
loss  of  dependence  on  highly  specialized  displays  and  systems,  more  inter-command  or 
distributed  wargaming  could  occur.  This  would  result  in  more  training  for  more  forces, 
with  obvious  benefits  accruing  therefrom. 

b.  Exercises 

Using  wargaming  in  conjunction  with  field  exercises  is  extremely  beneficial. 
Instead  of  being  limited  by  time  and  cost  constraints,  different  options  or  hard  to  field 
operations  can  be  conduaed.  The  availability  of  digitized  mapping  programs  and  the 
increasing  presence  of  highly  accurate  and  current  DMA  data,  would  allow  more  play¬ 
ers,  more  and  easier  access,  and  potentially  higher  quality  wargames  and  exercises. 
Again,  the  benefits  are  readily  apparent. 

3.  Other 

This  thesis  is  primarily  directed  towards  cartographic  products,  but  it  is  equally 
applicable  towards  other  graphics  products.  Strategic  analysts,  as  well  as  tactical 
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Figure  2.  Use  of  Digitized  Maps  in  Crisis  Situations:  Instant  accessibility  is  re¬ 
quired  by  the  on-scene  commander  and  the  crisis  management/action 


team. 


commanders,  monitor  the  activity  levels  of  numerous  indicators  [Ref.  3:  p.  86]  such  as 
enemy  order  of  battle,  troop  strength,  logistic  support,  levels  of  supplies,  casualty  rate, 
weather,  etcetera.  These  indicators  are  often  not  quantifiable  and  depend  on  some  other 
previous  analysis.  When  only  men  were  in  this  loop,  knowledge  of  the  general  situation 
and  of  the  other  analyst's  psyche  was  sufficient  to  judge  the  quality  of  a  decision.  The 
current  trend  in  technology  and  sensors  is  to  place  a  greater  reliance  on  the  use  of  Arti¬ 
ficial  Intelligence  (AI),  specifically  Expert  Systems.  Versions  of  these  AI  systems  process 
raw  sensor  data,  perform  primary  estimations,  and  then  elTect  dissemination  [Ref  3:  p. 
35).  This  is  the  best  solution  when  dealing  with: 


1.  High  threat  or  short  reaction  time  weapons  response. 

2.  Sensor  s\’stems  which  deliver  massive  amounts  of  raw  data  from  which  usable  in¬ 
formation  must  be  derived  through  algorithmic  processes. 

3.  Repetitive,  and  ver>’  subtle,  information  sources  where  changes  in  state  may  not 
be  detected  by  casual  or  distractable  observation.  Also  as  a  guard  against  mislead¬ 
ing  information  or  disinformation  where  the  target  observation  system  has  known 
liimtations. 

The  application  of  Expert  Systems  in  C3  is  ongoing;  however,  the  analyst  and 
commander  no  longer  know  the  man  who  is  feeding  tiiem  the  information  on  which  they 
are  basing  decisions  (and  possibly  lives).  These  AI,  Expert  Systems  are  generally  decision 
tree  or  probabilistic  based.  For  a  human  to  enter  into  this  system  in  the  middle  of  the 
cycle,  a  graphical  representation  of  the  AI  system's  knowledge  could  be  available.  In 
Decisio»'  Support  Systems  (DSS),  a  common  presentation  vehicle  is  the  Probable  Fu¬ 
tures  Map  [Ref.  3;  p.  121].  With  this  information,  a  commander  could  better  understand 
the  conclusions  and  recommended  options  from  his  intelligence  and  decision  support 
systems.  These  graphic  representations  are  easily  transmitted;  a  graphics  capable 
microcomputer  is  needed  to  display  them.  This  thesis  turns  one  of  DOD's  most  com¬ 
mon  microcomputers,  the  Zenith  Z-100  series,  into  an  available  graphics  terminal. 

B.  WHY  THIS  PROJECT  IS  IMPORTANT 

This  C2  problem  needs  to  be  addressed  with  a  C4  solution.  In  a  time  when  rapid 
transfer  of  data  is  common-place,  a  commander  should  no  longer  have  to  depend  on  a 
hard  copy  of  a  map  or  chart  being  carried  to  his  subordinates  and  superiors.  Neither 
should  the  tactical  co  nmander  be  tied  excessively  to  his  chart  bag  or  map  case. 

1.  Current  system 
a.  Requests 

The  current  system  requires  that  requests  for  cartographic  products  be 
submitted  to  D.MA  or  one  of  its  military  distribution  centers  for  issue.  The  tactical 
commander  usually  needs  one  or  two  copies  of  each  map  in  each  of  the  areas  he  is  ex¬ 
pected  to  operate.  This  relies  heavily  on  forethought  to  ensure  all  necessary  maps  are 
ordered  and  kept  on  hand.  The  burden  is  also  on  DMA  to  generate,  print,  store,  and 
then  distribute  maps  to  users.  Allowing  users  to  access  digitized  mapping  files,  develop 
their  own  projections  (usually  of  a  tactical  scale),  and  electronically  receive  the  product 
would  significantly  reduce  man-hours,  printing  costs,  and  warehousing  requirements. 
D.MA  would  need  to  develop  some  user  friendly  programs  in  order  to  allow  access  and 
to  maintain  high  standards  for  their  cartograpliic  products,  but  this  could  be  easily  ac- 
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complished  within  the  scope  of  current  assets.  The  recurring  theme  of  the  problem  tliis 
thesis  addresses  is  that  maps  and  charts  can  and  should  be  received  in  a  more  timely 
manner. 

b.  Contingency 

The  commander  and  his  staff  routinely  have  literally  hundreds  of  charts  and 
maps  which  are  carried  around  for  contingency  purposes.  These  maps  of  these  require 
continuous  updating  and  are  regularly  superceded  and  replaced.  The  requirement  to 
maintain  large  quantities  of  maps  adds  associated  logistic  and  manpower  burdens. 
There  is  a  need  for  an  alternate  means  of  obtaining  up  to  date  maps  and  charts  in  the 
fulfillment  of  a  contingency  requirement.'* 

2.  Suggested  Approach 

Commanders  should  be  able  to  transmit  their  situation  and  intentions  on  maps 
both  up  and  down  the  chain  of  command.  This  thesis  investigates  that  objective  using 
no  cost  or  government  proprietary  software  and  a  microcomputer  (the  Heath/Zenith 
100)  that  is  widely  available  and  well-suited  to  the  job  The  ability  to  pass  maps  and 
charts  electronically  has  several  significant  benefits  to  the  users,  the  mapping  agencies, 
and  DOD  as  a  whole.  Some  of  these  possible  benefits  are  listed  below: 

1.  Immediate  availability  of  high  quality,  updated  maps  and  charts  to  lower  echelon 
commanders.  Though  not  being  able  to  replace  typeset  printed  maps,  an  elec¬ 
tronically  transmitted  version  with  the  necessary  information  overlayed  or  imbed¬ 
ded  would  be  an  improvement  over  lesser  quality  products. 

2.  Independence  from  some  of  the  logistics  tail  of  most  commands  and  all  staffs,  that 
is  chart  bags,  map  cases,  and  their  associated  files.  .Maps  and  charts  for  locations 
not  in  a  commands  area  of  responsibility  (AOR)  could  be  called  electronically, 
rather  than  keeping  a  hard  copy  on-hand. 

3.  Decreased  requirement  for  D.MA  printed  maps  and  more  time  available  to  order 
correct  maps  and  charts  before  the  detailed  planning  and  execution  phases. 

4.  Decrease  in  manpower  requirements  to  keep  ch«irt  and  map  allowances  updated. 
The  emphasis  on  maps  and  charts  for  a  command's  AOR  being  always  up  to  date 
and  other  areas  being  available  on-call  electronically. 

5.  Better  utilization  of  common,  general  purpose  military  microcomputers  for  more 
missions. 

*  The  needs  of  a  tactical  commander  cannot  be  fulfilled  by  this  type  of  system  at  this  time. 
The  transfer  of  tactical  quality  maps  electronically  is  currently  an  option  using  specialized  graphics 
terminals  only,  however  this  capability  has  been  extended  to  some  major  .Air  Force  C2  commands 
as  of  this  writing  (see  Chapter  I.I3.3.a  below). 


a.  Electronic  distribution 

DOD  agencies  have  started  using  the  Defense  Mapping  Agencies  (DMA) 
database  of  digitized  maps.  This  is  usually  accomplished  with  a  dedicated  mainframe  and 
a  graphics  workstation.  Accessing  the  DMA  World  Data  Bank  II,  one  can  build  maps 
of  any  location  in  the  world.  To  build  the  map,  enter  the  center  of  the  desired  map  and 
then  the  directional  distances  from  the  center  to  be  displayed.  The  system  automatically 
retrieves,  draws,  and  then  scales  the  map.  Features  include  coastlines,  waterways,  poli¬ 
tical  boundaries,  roads  and  railroads;  additionally,  latitude  and  longitude.  UTM.  or 
GEOREF  grid  systems  can  be  overlayedfRef.  4:  p.  44]. 

b.  Generation 

In  addition  to  accessing  DMA  maps,  mainframe  computers  can  also  be  used 
to  maintain  their  databases  of  graphics  software.  Cartographic  products  generated 
by  these  programs  could  be  sent  and  received  throughout  the  chain  of  command.  The 
ability  to  send  and  receive  graphics  products  up  and  down  the  chain  of  command  would 
result  in  consistent  quality  of  information  and  less  confusion  due  to  interpretation  of  the 
written  words  .  A  side  benefit  could  also  be  realized  with  the  distribution  of  other 
graphics  products  for  visual  affect  and  emphasis. 

c.  Existing  systems 

There  currently  exist  several  digitized  mapping  programs  for  microcomput¬ 
ers.  Many  are  available  through  user's  groups  and  via  computer  bulletin  boards,  but 
all  of  them  have  limitations  which  will  not  fulfill  the  requirements  of  this  thesis.  A  brief 
review  of  some  of  these  products  follows. 

(1)  Map  Maker.  The  program  Map  .Maker  produces  two  forms  of 
quantitative  maps:  choropleth  (area  coloring)  and  graduated  circles.  Any  set  of  statis¬ 
tical  values  may  be  displayed  for  its  corresponding  geographic  area.  .Map  areas  are 
limited  to  states,  counties,  census  tracts,  or  areas  defined  by  the  user.[Ref.  5:  p.  67]  This 
program  is  typical  of  those  developed  for  the  social  sciences  and  demographics.  Its  re¬ 
solution  and  accuracy  would  probably  be  inadequate  for  military  purposes. 

(2)  World  Map.  This  software  allows  users  to  generate  a  world  map  on 
the  screen  and  even  to  zoom  into  various  areas.  Only  boundary  lines  are  drawn  on  the 
map  and  there  are  no  details.  The  map  is  very  good  for  allowing  the  user  to  set  a  latitude 
and  longitude  and  then  zoom  in  on  the  area  in  question.  A  number  of  cities  and  capitals 
are  given  and  can  be  located  and  zoomed  in  on  from  the  world  map.  [Ref  5:  p.  83]  This 


5  A  picture  is  worth  a  thousand  words. 


program  could  be  useful  to  the  strategic  level  planner  who  is  only  concerned  with  low 
cartographic  resolution  maps.  Lack  of  data  points  would  seriously  hinder  lower  level 
planners  who  require  greater  accuracy  and  detail. 

(1)  World  Digitizer.  Another  new  map  generation  program  is  World 
Digitizer  which  has  a  similar  capability  to  World  .Map,  described  above.  It  is  written  in 
the  language  C  and  performs  all  of  its  functions  very  quickly.  The  data  it  uses  to  gen¬ 
erate  maps  is  composed  of  one  million  conneaed  latitude  and  longitude  points.  This  is 
the  first  program  reviewed  which  specifically  warns  the  user  of  its  inaccuracies.  Its  ap¬ 
plication  to  strategic  and  operational  planners  uses  is  possible. 

(4)  Micro  DEM,  formerly  Terrain  Analysis.  This  program  provides  dig¬ 
ital  topographical  support.  The  program  uses  Digital  Terrain  Elevation  Data  (DTED) 
Level  I  produced  by  DMA,  but  the  characteristics  of  the  data  limit  its  capability  and 
require  careful  analysis  of  its  results.  The  program  can  dump  to  a  printer  line  of  sight 
profiles,  weapons  or  sensor  masking  plots,  color  tinted  elevation  maps,  slope  maps,  and 
three  dimensional  oblique  views.  Data  sets  used  by  the  computer  cover  15  minutes  of 
longitude,  which  corresponds  to  a  standard  tactical  map.  Programs  are  available  for  the 
Fulda  Gap  (16  disks),  the  Korean  DMZ  (5  disks),  and  Fort  Irwin/West  Point  (11  disks). 
[Ref.  5:  p.  IS]  This  program  is  highly  accurate  and  is  updated  regularly.  However,  the 
logistics  trail  to  provide  replacement  and  corrected  disks  would  represent  no  major  im¬ 
provement  over  the  existing  system  with  regards  to  logistics,  manpower  burden,  nor 
timeliness.  Exploration  of  this  system  resulted  in  this  thesis  advocating  the  use  of 
mainframe  computers  to  generate  the  maps  required,  whether  organically  produced  or 
drawn  from  DMA  data.  Regardless  of  the  microcomputer  advocates'  claims  that  their 
machines  can  do  it  all,  some  jobs  remain  too  large.  The  microcomputer  is  better  used  to 
display  a  map  the  mainframe  has  stored  for  it,  and  then  to  print  it. 

3.  Direction  of  Computer  Mapping 

There  exist  two  distinct  categories  in  which  the  military  commander  or  his  staff 
would  need  to  generate  maps.  The  first  is  the  strategic  and  operational^  levels  of  com¬ 
mand.  The  requirement  would  be  for  large  area,  small  scale  maps  on  which  a  commander 
could  place  symbology,  icons,  or  text  for  broad  direction  and  situational  reporting. 
Accuracy  and  resolution  quality  would  be  secondary  to  convenience  and  speed  of  use. 
Ideally,  situation  reports  and  concept  of  operation  maps  could  be  prepared*  easily  stored 

6  Operational  level  of  command  can  be  roughly  equated  to  the  theater  level  or  the  area  in 
which  a  corps  commander  would  operate. 


and  instantly  accessible  to  subordinates  and  superiors.  The  maps  could  readily  be  played 
back  by  remote  units  requiring  only  a  small  graphics  capable  computer  and  a  modem 
(Ref.  6).  The  second  situation  occurs  when  lower  level  users  employ  maps  and  charts 
for  tactical  purposes.  The  programs  mentioned  in  the  previous  section  either  lack  suffi¬ 
cient  resolution  or  require  dozens  of  computer  data  disks  to  present  a  specific  area.  The 
resolution  problem  is  unacceptable,  when  resolution  needs  to  be  10  meters  or  less.  The 
multiple  disk  problem  offers  no  logistical  or  timeliness  improvement  over  the  current 
system  of  carrying  bundles  of  charts  or  maps.  Tliis  situation  would  require  that  the 
maps  be  created  from  a  highly  accurate  and  continuously  updated  cartographic  data¬ 
base.  Access  to  DMA  online  digitized  maps  would  be  a  necessity.  Some  attempts  at 
integrating  the  D.MA  data  bases  into  a  real-time  enviroment  are  being  attempted.  A 
sampling  of  these  programs  tollow. 

a.  TRACE 

The  U.S.  Air  Force  is  currently  purchasing  an  automated  decision  support 
tool  for  C3I  called  Tactical  Resource  Allocation  for  Combat  Effectiveness  (TRACE). 
This  system  is  available  from  Lockheed  Missiles  and  Space  Company  or  through  Chro¬ 
matics,  Inc.  The  object  is  to  develop  a  flexible  and  transponable  system  which  can  allow 
a  command  center  to  reduce  time  in  resource  planning  and  allocation.  TR/\CE  runs  on 
a  Digital  Electronics  Corporation  (DEC)  VAX  computer  with  the  Chromatics  CX1536 
High  Resolution  Graphics  display.  The  programming  is  in  Fortran  and  Graphical  Kernel 
System  (GKS).  This  combination  of  hardware  and  software  allows  real-time  generation 
of  maps  using  D.MA  digitized  data.[Ref  4;  p.  44,  46)  Though  this  system  works  at  the 
command  level,  it  is  too  hardware  dependent  ever  to  become  available  at  the  tactical 
level.  Soon,  this  system  will  allow  the  strategic  and  operational  planners  to  generate 
hign  quality  maps  and,  hopefully,  to  disseminate  them  to  lower  echelon  commanders. 

b.  NationiU  Marine  Fisheries  Services 

The  National  Marine  Fisheries  Services  (NMFS),  which  operates  under  the 
National  Oceanagraphic  and  Atmospheric  Agency  (NOAA),  has  been  developing  the 
capability  of  a  small  graphics  capable  computer  to  display  DMA  or  NOAA  maps  and 
charts.  The  computer  emulates  a  Tektronix  4010  Graphics  Display  (similar  to  the  em¬ 
ulator  used  in  this  thesis)  and  the  reports  indicate  that  the  concept  is  feasible.  Opera¬ 
tional  evaluation  was  conducted  at  Galveston,  Texas.  [Ref  7] 
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c.  Future  DMA  products 

DMA  is  in  the  process  of  deveioping  a  film  digitization  capability  which 
would  be  used  in  the  future  for  a  digital  point  positioning  data  base  product. [Ref.  8] 
Access  to  this  type  of  information  would  be  available  via  the  same  means  as 
cartographic  data  and  could  be  similarly  displayed.  This  is  another  tactical  tool  which 
can  be  utilized  and  should  be  explored  in  the  future. 


II.  METHODOLOGY 


A.  APPROACH 

This  thesis  will  identify  all  components  of  a  Low  Cost  Graphics  (LO-CO-GRAF) 
system  to  address  the  problem  of  generating  maps,  transferring  the  maps  between  users, 
and  producing  a  hard  copy  of  that  map  from  a  command,  control,  communication 
and  computer  (C4)  perspective.  Computing  and  communicating  between  computers 
and  data  networks  will  be  the  central  focus  of  the  approach,  with  an  additional  re¬ 
striction  that  this  be  a  no/low  cost  solution  to  the  problem.  With  the  appropriate 
set  of  equipment  and  software  attributes,  'ommanders  can  enlist  the  aide  of  com¬ 
puters  to  ease  some  of  the  burdens  of  command  and  control.  The  combined  use  of 
mainframe  computing  power  and  the  ability  to  communicate  or  translate  that  pow'er 
to  smaller  more  accessible  computers  will  provide  a  valuable  tool  to  the  commander  and 
the  command  and  control  function.  The  set  of  remote  "source"  systems  that  generate 
the  graphics,  local  microcomputers,  communications  software,  the  graphics  terminal 
emulator  software  program  and  the  software  required  to  print  out  graphics  products 
will  comprise  the  LO-CO-GRAF  system.  As  seen  in  Figure  3,  which  provides  an  over¬ 
view  of  the  system  architecture  and  components,  communications  software  will  enable 
each  remote  terminal  to  transfer  data  from  the  mainframe  computer  (or  other  graphics 
source  system)  to  other  user  terminals.  The  programs  required  to  send  the  electronic 
maps  are  available  for  most  microcomputers  and  are  an  essential  component  of  the 
system.  The  program  required  to  playback  or  display  the  maps  can  be  transferred  within 
the  system's  terminals,  as  well  as  the  printing  programs. 

1.  Advantages 

The  LO-CO-GRAF  system  will  take  advantage  of  the  high  quality  graphics 
programs  and  large  storage  potential  characteristically  available  on  mainframe  com¬ 
puters,  while  using  them  to  perform  the  calculating  and  plotting  functions  required  to 
produce  maps  and  other  high  quality  graphics.  Taking  this  approach  will  overcome 
some  of  the  problems  encountered  by  other  map  generation  programs  which  tried  to 
perform  all  of  the  functions  on  the  microcomputer.  Utilizing  a  mainframe  also  takes 
advantage  of  the  fact  that  the  database  is  constantly  being  updated  by  the  Defense 
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Figure  3.  The  LO-CO-GRAF  System  architecture. 

Mapping  Agency,  providing  up-to-date  information."  The  C2  community  must  be  able 
to  access  this  information  from  remotely  located  terminals  in  order  to  obtain  the  greatest 
benefits.  With  the  aid  of  a  communications  software  package  and  terminal  emulator 
this  can  be  accomplished  at  little  or  no  cost  by  utilizing  equipment  assets  already 
available  to  most  organizations. 

2.  Distributed 

Doing  the  work  remotely  is  a  major  point  where  LO-CO-GRAF  departs 


7  Being  able  to  access  and  process  the  DMA  databases,  that  is  the  digitized  cartographic  pro¬ 
ducts,  as  they  become  available  circumvents  the  delay  associated  with  the  logistics  lag  time  involved 
with  ordering  maps. 


from  similar  graphics  programs. 8  By  accessing  a  remote  source  which  will  actually 
generate  the  derived  graphics  and  by  keeping  that  function  separate,  the  microc  jmputer 
is  free  from  the  major  task  of  maintaining  the  sizable  database  required  to  generate 
the  maps  and  avoids  the  problem  of  trying  to  manipulate  and  process  all  that  data. 
After  downloading  the  high  quality  graphics  products  from  maimfame  computers  and 
other  sources,  it  can  be  translated  to  a  form  that  can  be  understood,  displayed,  stored, 
redisplayed,  and  transmitted  to  other  users.  There  are  commercial  and  military  hard¬ 
ware  and  software  packages  available  that  provide  the  capability  to  process  DM.A 
data  or  generate  maps  and  other  higher  level  grapliics.  Unfortunately  these 
systems  are  very  costly  and  require  too  much  memory  storage  capability  or  too 
many  hardware  enhancements  to  be  widely  employed  without  incurring  large  costs  to 
implement.  The  objective  of  this  thesis  is  to  demonstrate  that  a  system  could  be  made 
widely  available  at  no  cost  to  the  users,  by  taking  advantage  of  existing  assets. 

To  accomplish  this  goal,  it  is  necessary  to  make  a  few  starting  assumptions. 
First,  what  is  the  working  environment?  And  then,  what  equipment  can  be  expected 
to  be  available  in  the  C2  community? 

B.  ASSUMPTIONS 

The  first  assumption  is  that  the  LO-CO-GRAF  system  should  be  capable  of 
transmission  over  telephone  networks.  This  type  of  operation  will  allow  the  head¬ 
quarters  or  the  central  C2  controlling  node  to  bring  in  other  new  members  and  share 
the  graphics  among  a  set  of  operational  units  or  commands.  The  only  requirement  is 
that  that  unit  have  a  similar  set  of  hardware  and  software  available. 

Some  hardware  is  uiiiversally  available  to  support  the  C2  components  wishing  to 
use,  produce  and  transmit  graphics  products.  The  software  required  will  be  intro¬ 
duced  or  provided  as  a  by-product  of  this  thesis.  The  real  contribution  of  the 
LO-CO-GRAF  system  is  the  ability  not  only  to  obtain  the  graphics,  but  also  to 
transmit  any  maps  generated  along  with  the  software  necessary  to  use  it.  Some  as¬ 
sumptions  follow  about  the  working  environment  and  the  assets  available. 

S  Microdem  and  Terranal.  for  c.xample,  use  data  which  has  been  processed  and  prepared 
to  enable  a  small  computer  to  then  generate  maps  locally.  One  problem  with  this  process  is  that 
you  need  to  keep  all  the  data  on  hand  locally  and  then  reprocess  it  as  needed.  The  data  disks 
required  are  very  cumbersome  and  are  just  as  dillicult  to  keep  current  logistically  as  paper  maps. 
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1.  Sources 

High  quality  graphics  products  are  available  on  many  mainframe  computers 
which  are  capable  of  processing  raw  data  and  generating  maps.  .Most,  if  not  aU, 
mainframe  computers  have  resident  programs  to  perform  high  quality  grapliics  func¬ 
tions.  The  graphics  programs  are  either  capable  of  generating  their  own  maps,  as  in  the 
case  of  Display  Integrated  Software  System  and  Plotting  Language  (DISSPLA)  pro¬ 
gram,  or  are  capable  of  processing  DMA  data  to  plot  maps  from  raw  data. 

In  the  case  of  a  remotely  located  C2  terminal,  the  mainframe  will  not  be  acces¬ 
sible  by  a  direct  connection  to  the  microcomputer.  Connecting  will  require  access 
through  some  communications  system  in  order  to  make  the  grapliics  program  available. 
"Available"  means  obtaining  access  to  the  mainframe  through  a  modem  and  communi¬ 
cations  software  package  or  communicating  to  some  other  graphics  generating  facility, 
such  as  those  available  on  the  Defense  Digital  Network  (DDN).  In  either  case,  the 
operative  word  is  available.  An  additional  requirement  for  this  thesis  is  to  implement 
LO-CO-GRAF  at  no  additional  cost.  Next,  the  problem  of  establishing  communi¬ 
cations  between  the  remote  mainframe  (or  other  map  source)  and  the  local 
microcomputer  must  be  addressed  and  resolved. 

2.  Communications 

Communications  software  is  readily  available  at  no  cost  as  freeware  or  Gov¬ 
ernment  proprietary  software  and  in  most  cases  is  already  available  on  a  mainframe 
computer  available  to  the  potential  users.  If  no  communication  software  package  is 
available,  one  must  be  obtained,  again  at  no  cost,  in  order  to  stay  within  the  low  cost 
(no  cost)  objective.  This  thesis  assumes  there  is  a  communications  software  package 
available  which  will  enable  communications  between  the  remote  map  generating  system 
and  the  local  microcomputer. 

For  the  case  where  no  communications  system  is  available  to  provide  access 
to  the  mainframe,  instructions  for  obtaining  the  software  will  be  provided  within  this 
thesis.  The  software  must  be  adaptable  to  as  many  different  mainframe  computers  as 
possible  to  allow  access  to  all  the  many  types  of  graphics  source  machines  available. 
The  communications  software  must  also  provide  for  communications  between  the 
graphics  sources  and  to  the  microcomputer. 

3.  Microcomputer 

The  microcomputer  must  be  capable  of  translating  and  processing  the 
graphics  data.  The  Zenith  Data  System  Z-100  microcomputer  is  both  capable  and 
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available.  There  are  many  Z-100  computers  in  the  military  inventory  which  are  not 
utilized  to  their  full  capability’.^  The  Z-100  was  chosen  because  it  has  very  good  built-in 
graphics  capabilities,  which  will  be  discussed  later  in  greater  detail  in  Chapter  III. 

To  take  full  advantage  of  the  resident  graphics  capability  of  the  Z-100,  a 
software  program  will  be  developed  and  documented  as  part  of  this  thesis  to  make  it 
emulate  a  standard  high  quality  graphics  terminal.  Through  emulation,  the  Z-100  will 
gain  the  ability  to  process,  display,  and  store  (map)  graphics.  After  storing  the  data, 
the  last  step  is  to  be  able  to  recall  or  redraw  those  saved  images  as  well  as  print  them 
out  on  paper. 

4.  Printers 

The  last  assumption  is  that  there  will  be  a  requirement  to  print  any  maps  or 
other  images  which  are  generated  by  LO-CO-GRAF.IO  Choosing  a  graphics  screen 
dump  program  which  applies  to  several  of  the  more  common  miUcary  printers  will  pro¬ 
vide  a  way  to  print  any  map  images  saved  by  the  terminal  emulator  program. 


9  The  major  reason  for  not  fully  utilizing  the  Z-100  capabilities  is  that  they  are  neither  soft¬ 
ware  nor  hardware  compatible  with  the  more  recent  and  popular  International  Business  Machine 
(IB.M)  personal  computer  (PC)  machines.  The  differences  are  e.\amined  in  detail  m  Chapter  III.C. 

10  There  are  many  dot  matri.x  printers  througliout  the  DOD  in  both  militarize^  and  com¬ 
mercial  versions.  The  Epson  .MX,  Oladata  Microline,  and  Zenith  MPI-99'150  series  cot  matri.x 
printers  are  e.\amples  of  standard  DOD  printers. 
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III.  TECHNICAL  EXPLANATION 
A  MAP  GENERATION 

The  ability  to  generate  maps  for  strategic  or  theater  level  operations  is  commonly 
available  in  mainframe  graphics  programs.  The  mapping  characteristics  may  include  a 
variety  of  coastlines,  political  boundaries,  and  waterways,  as  well  as  selection  between 
the  different  types  of  projections.  The  major  limitation  is  that  only  a  limited  number  of 
data  points  have  been  saved  for  the  maps  to  be  drawn  from.  Two  unique  resolution 
problems  are  encountered  while  creating  maps.  First,  the  aforementioned  lack  of  data 
points  can  only  generate  maps  with  resolution  measured  in  kilometers  (possibly  fractions 
of  kilometers).  An  example  of  this  type  of  resolution  problem  can  be  seen  in  Figure  4. 
Secondly,  display  resolution  is  limited  by  the  type  of  computer  monitor  being  used  and 
also  by  printer  resolution  characteristics. 

1.  Resolution  Problems 

The  standard  definition  of  resolution  is  the  smallest  distance  between  two  dif¬ 
ferent  points  that  is  distinguishable.  In  printer  terms,  the  expression  used  is  "dots  per 
inch"  or  dpi  (a  typical  laser  printer  can  perform  300  dpi  or  resolution  to  1,  300  of  an 
inch).  For  computer  monitors,  resolution  is  stated  in  the  number  of  pixels,  that  is,  the 
number  of  points  on  a  screen  displayed  vertically  and  horizontally.  The  number  of  dots 
per  inch  is  not  fixed  by  the  computer  screen,  though.  Just  as  a  television  picture  looks 
less  grainy  on  a  small  screen,  a  computer  monitor  with  a  13-inch  screen  will  look  better 
than  a  19-inch  screen.  This  is  because  the  picture  is  really  made  up  of  a  fixed  number 
of  pixels,  the  larger  the  screen  then  the  further  apart  the  dots  will  be  [Ref.  9:  p.  34). 
Resolution  can  be  changed  by  the  user  in  both  the  horizontal  and  vertical  by  adding 
hardware  upgrades  to  the  graphics  circuitry,  therefore  manufacturers  refer  to  the  total 
number  of  pixels  displayed.  A  common  example  would  be  the  Color  Graphics  Adapter 
(CGA),  which  has  a  color  resolution  of  320  by  200. 

Table  1  presents  a  sampling  of  devices,  their  actual  resolution,  and  their  pres¬ 
entation  characteristics.  These  numbers  must  naturally  be  compared  to  the  visual  acuity 
of  the  human  eye.  Typically,  a  person  can  distinguish  objects  one  degree  apart  at  six 
feet.  Human  vision  remains  highly  dependent  on  distance,  contrast,  color  and  shading, 
shapes,  brightness  and  darkness,  and  the  viewer's  age  (Ref  10). 
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Figure  4.  Example  of  resolution  problems:  Map  of  Washington,  DC  area. 


Returning  to  the  television  example,  a  typical  television  monitor  only  produces 
200  lines  of  resolution,  much  less  than  that  possible  witii  a  graphics  adapter.  Yet  to  the 
e>'e  it  is  more  than  sufficient  to  portray  an  image.  The  reason  for  this  is  the  large  number 
of  colors  or  shadings  being  used.  This  multi-color,  low  resolution  technique  is  excellent 
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Table  1.  SAMPLE  RESOLUTIONS 


Screen  Resolution 


320  X  200  on  13” 


640  X  480  on  13"  (Z120) 


1024  X  76S  on  16" 


1536  X  1152  Chromatic 
CX1536  (TR^ACE) 


Dot  matrix  printer 
(standard  9-pin) 


24-pin  dot  matrix  printer 


Laser  printer 


Typesetter 


Actual  Resolution 


36  ppi  (horizontal) 
30  ppi  (vertical) 


72  ppi 


90  ppi 


Lines;  char 

@  12  pt 


5 


up  to  240  dpi 


up  to  360  dpi 


300  dpi  (typical) 


1200  dpi 


Taken  in  part  from  [Ref.  9:  p.  36]  and  manufacturer's  specifications. 


when  displaying  real-life  images,  but  inadequate  for  text  images  [Ref.  9  :  p.  35].  The 
problem  is  heightened  by  the  intense  resolution/ accuracy  requirements  needed  for 
mapmaking.  The  anti-aliasing  schemes  used  to  improve  the  appearance  of  text  on  a 
monitor  would  only  introduce  error  into  cartographic  representations. 

2.  DISSPLA 

The  graphics  package  available  on  the  IBM  3033  mainframe  computer  at  NPS 
is  the  DISSPLA  program.  This  system  was  developed  by  Integrated  Software  Systems 
Corporation  (ISSCO)  of  San  Diego  and  is  widely  used  throughout  the  Navy,  DOD,  in¬ 
dustry,  and  other  academic  institutions  [Ref.  11].  According  to  DISSPLA,  any  desired 
graphics  product  can  be  achieved  within  one  to  two  hours,  using  the  interactive  system. 
Some  of  the  products  include  specialized  business,  cartographic  projections  (of  interest 
to  this  thesis),  and  a  dynamics  program.  AH  of  which  are  detailed  for  practical  applica¬ 
tions  in  the  DISSPLA  User  Guide  [Ref  12]. 

Automated  graphics  is  a  powerful  and  useful  computer  application  of 
significant  importance  to  distributive  computing  and  wargaming  in  the  military.  The 
capability  to  plot  computer  generated  maps  on  demand  is  an  essential  tool  for  opera- 


tional  commanders,  as  well.  There  are  many  software  packages  which  provide  programs 
of  commands  and  subroutines  to  produce  very  powerful  graphics  outputs.  The 
geographic  data  required  to  plot  the  maps  is  stored  in  mass  storage  in  several 
resolutions[Ref.  12:  Part  D],  which  can  be  called  to  generate  maps  of  various 
projections. 

a.  Programming 

DISSPLA  was  developed  using  Fortran  IV  constructs.  Current  Fortran 
compilers  use  Fortran  77  or,  if  an  IBM  system,  VS  Fortran.  Both  are  fully  backwards 
compatible  and  have  the  greater  variety  of  options  for  entering  data  which  aids  in 
cartographic  design  and  engineering. 

The  DISSPLA  package  is  actually  a  library  of  FORTRAN  subrou¬ 
tines  which  can  be  called  and  arranged  with  other  FORTRAN  source  code  to  gen¬ 
erate  the  desired  map.  It  required  a  great  deal  of  time  to  learn  how  to  organize  these 
subroutines  to  generate  maps  and  plotting  a  few  maps  of  different  theaters  of  opera¬ 
tion  to  show  the  power  of  this  DISSPLA  option. 

The  process  of  calling  subroutines  at  various  levels  within  the  DISSPLA 
package  is  perhaps  the  most  difficult  concept,  but  not  the  first  that  can  cause  trouble. 
To  use  DISSPLA  means  one  will  interface  through  a  set  of  more  than  300  user-  call¬ 
able  subroutines.  The  subroutines  access  a  network  of  usually  invisible  (except 
when  an  error  condition  occurs),  internal  sub-subroutines  which  communicate  with 
each  other  using  blocks  of  more  than  200  variables.  As  can  be  seen,  calling  a  subrou¬ 
tine  is  no  simple  matter.  The  logic  flow  in  DISSPLA  is  unidirectional  through  more 
than  twenty  levels  of  subroutines. 

By  levels,  it  is  meant  that  a  call  on  one  subroutine  may  do  nothing  more 
than  set  a  parameter  or  flag  a  variable  for  use  by  another  subroutine,  or  a  subroutine 
occurring  later  on  in  the  program.  Calling  a  subroutine  that  depends  on  another 
subroutine  which  has  not  already  been  called  will  cause  you  to  go  into  computer 
"N'ever-Never"  land.  Fortunately,  to  generate  maps  one  will  only  have  to  specifically 
address  four  kinds  of  routines  to  change  to  proper  levels. 

The  program  listings  in  Appendixes  A  and  B,  emphasize  comments  which 
show  the  transitions  between  programming  levels.  Using  the  programs  listed  in  Ap¬ 
pendix  A,  one  will  not  need  to  know  a  great  deal  about  the  levels  to  generate  maps, 
but  should  understand  that  they  exist  and  can  cause  great  difficulty  when  generating 
complicated  plots  if  they  are  not  accessed  in  the  correct  order.[Rcf  11] 
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b.  Running  DISSPLA  \ 

To  use  DISSPLA  under  VM/CMS,  one  must  link  to  the  support  disks  j 

which  contain  the  data  files.  This  involves  establishing  appropriate  input  and  ‘ 

output  files,  file  definition  statements,  and  text  library  programs,  which  is  a  tedious  and  | 

time  consuming  process.  There  is  an  execH  ,  DISSPLA  EXEC,  that  must  be  used  to  j 

actually  run  a  program  and  link  to  all  the  appropriate  files  and  create  the  correct  envi-  j 

ronment  to  work  in  DISSPLA.  ’ 

An  on-line  help  file  is  available  by  typing  "disspla  ?".  Althouch  this  file  is  i 

helpful,  it  does  not  make  it  easier  to  create  three  dimensional  plots  (maps  are  two  [ 

dimensional  projections  of  three  dimensional  data  points)  nor  does  it  address  how  to  I 

I 

generate  a  map  specifically.  The  most  valuable  source  of  information  for  plotting  maps  ^ 

is  contained  in  the  DISSPLA  Pocket  Guide  [Ref.  12:  Part  D).  It  contains  several  ex-  [ 

ample  programs  with  more  information  about  the  caUing  of  map  plotting  subroutines.  i 

c.  DISSPOP  option  j 

When  the  DISSPOP  option  of  DISSPLA  is  called,  the  output  is  a  device  i 

independent  plot  file,  rather  than  an  actual  plot.  This  file  is  called  a  metafile  and  is  highly 
compressed.  It  can  be  interpreted  by  one  of  a  selection  of  post-processor  programs  for 
output  to  a  particular  device.  [Ref.  12:  p.  F-l]  Exercising  the  DISSPOP  option,  or  a 
similar  capability  under  a  different  graphics  program,  a  commander  could  generate  the 
map  or  chart  with  any  necessary  information  attached  and  then  store  it.  Any  subordi¬ 
nate  or  superior  with  a  graphics  device  listed  in  the  DISSPOP  post-processor  device 
menu  could  then  instantly  retrieve,  display,  and  print  (if  they  also  have  that  capability) 
these  maps  and  charts.  The  use  of  a  device  independent  plot  file  will  have  to  be  a  ca¬ 
pability  included  in  a  command  center's  map  generation  program. 

B.  COMMUNICATION 

The  second  part  of  the  solution  involves  establishing  a  way  to  communicate  be¬ 
tween  the  mainframe  and  a  remote  microcomputer.  Computer  to  computer  communi¬ 
cations  requires  a  working  knowledge  of  the  technical  characteristics  of  both  machines, 
a  modem,  and  a  basic  understanding  of  communications  software.  First,  a  discussion 
of  the  functions  of  the  modem  and  how  it  provides  the  connection  between  the  remote 
graphics  generating  system  and  the  microcomputer. 

1 1  .\n  exec  is  an  executable  file,  which  when  called  will  initiate  programs  and  confmure  your 
operating  system  or  virtual  machine  for  a  specific  task. 


21 


1.  Modems 


There  are  two  basic  modem  configurations,  internal  and  external.  Elec¬ 
trically  there  is  no  difference  and  the  procedures  that  follow,  as  well  as  the  software  to 
be  provided/introduced,  will  work  with  either  variety.  All  modems  arc  rated  in  terms 
of  their  transmission  speed.  The  ratings  are  in  baudi2  (e.g.  300,  1200,  2400,. .etc.), 
which  refers  to  the  number  of  bits  per  second  the  modem  is  capable  of  transmitting  or 
receiving.  A  1200  baud  modem  will  transmit  and  receive  data  four  times  faster  than 
a  300  baud  modem,  and  half  as  fast  as  one  rated  at  2400  baud.  .Most  communications 
software  systems  today  allow  connection  at  any  speed,  but  the  faster  the  better. 

2.  Communication  Software 

A  communications  software  program  is  used  to  access  a  communications 
network  or  remote  system.  This  allows  the  microcomputer  to  dial  the  necessary 
telephone  numbers,  establish  an  electrical  connection,  and  then  communicate  with  the 
remote  system.  The  remote  system  may  be  a  mainframe  computer,  another 
microcomputer  or  a  data  communications  network,  like  the  Defense  Data  Network 
(DDN).  The  main  function  of  this  software  is  to  make  the  remote  system  recognize  your 
microcomputer  as  an  input/output  terminal. 

By  electrically  looking  like  an  input/output  terminal,  the  microcomputer  can 
talk  to  the  remote  system  over  telephone  lines  as  if  it  were  connected  (hardwired)  to  the 
other  computer  system  directly.  Most  communications  software  programs  will  also 
allow  transfer  of  files  and  programs  from  the  microcomputer  to  the  remote  system  and 
vice  versa.  The  file  transfer  feature  will  play  an  important  part  in  the  LO-CO-GRAF 
network  so  it  is  important  to  select  a  program  which  utilizes  a  standard  communications 
protocol.  The  communications  software  package  selected  for  this  thesis  has  been  de¬ 
veloped  for  over  200  different  computers  and  microcomputers. 

3.  KERMIT 

KERMIT  actually  stands  for  KllO  Error-free  Reciprocal  Microcomputer 
Interconnection  over  Teletype  (TTY)  lines.  This  computer  communications  protocol 
designation  was  established  when  CP/.M  was  the  preferred  microcomputer  operating 
system  and  it  was  not  changed  as  the  system  was  later  developed  for  use  with  other  disk 
operating  systems  (DOS). 


1 2  Baud  rate  is  a  measurement  of  the  capacity  of  a  communications  channel  to  pass  informa- 
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KERMIT  was  developed  and  written  at  the  Columbia  University  Center  for 
Computing  Activities  as  a  packet  switched  file  transfer  and  communications  pro¬ 
gram.  KERMIT  is  not  necessarily  better  than  other  programs  but  it  is  free  and  it 
has  been  adapted  for  use  on  many  micro,  mini,  and  mainirame  computers.  The  partial 
list  in  Figure  5  shows  a  few  of  the  more  popular  versions. 

Every  version  that  has  been  implemented  is  available  from  the  Columbia 
University  KER.MIT  Distribution  Center.i3  The  program  can  be  downloaded  by  any 
file  transfer  system  with  a  modem  connection  or  by  accessing  the  distribution  center 
tlirough  an  electronic  data  system  like  the  Defense  Data  Network  (DDN).  A  com¬ 
plete  set  of  instructions  are  available  (Appendix  D)  which  provide  all  the  instructions 
necessary  to  access  the  KERMIT  archives.  Once  you  have  obtained  a  copy  of 
KER.MIT  it  must  be  set-up  with  the  correct  parameters  to  use  it  in  the  LO-CO-GR.APH 
system,  i-t 

4.  Utilization 

There  is  a  very  exhaustive  manual  available  in  disk  format  which  explains  all 
the  parameters  and  options  for  using  KERMIT.  It  is  beyond  the  scope  of  tliis  thesis 
to  explore  all  the  abilities  of  the  program  itself.  An  instruction  guide  which  explains 
all  the  steps  necessary  to  operate  KER.MIT,  as  required  for  the  LO-CO-GRAPH  sys¬ 
tem,  appears  as  Appendix  E. 

The  KERMIT  instruction  guide  is  written  specifically  to  allow  connection  of  the 
Zenith  Z-IOO  to  the  International  Business  Machines  (IBM)  370  naainframe.  It  is 
not  necessary  to  know  anything  more  about  KERMIT  to  use  it  as  the  communi¬ 
cations  software  in  this  system.  Minor  modifications  to  the  set-up  procedure  will  al¬ 
low  connection  to  the  Defense  Data  Network. 

Connection  to  the  DDN  and  or  mainframe  will  allow  access  to  a  graphics 
program  designed  to  generate  high  quality  graphics  and  maps.  These  programs 
require  a  graphics  terminal  or  workstation  quality  monitor  in  order  to  display  the 
graphics.  This  leads  into  the  next  area  of  the  project.  It  is  necessary  now  to  make  the 
remote  graphics  source  system  think  the  microcomputer  is  a  graphics  processing  termi¬ 
nal. 


13  The  center  maintains  a  file  (.Appendix  C)  on  their  computer  which  contains  a  much 
more  comprehensive  list  of  KERNIIT  applications  and  provides  all  the  information  needed  to 
find  the  correct  version  for  your  computer. 

14  This  will  be  discussed  at  length  in  Chapter  IV. 
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Micros  and  Workstations 

Apollo 

Aegis 

Pascal 

Apple  II 

DOS  3.  3  or  ProDos 

6502  Assembler 

Atari  ST  Series 

GEM 

C 

Commodore  64 

DOS 

CROSS  (or  FORTH*) 

DEC  Professional-3S0 

P/OS 

Bliss 

Honeywell  L6/10 

MS-DOS 

flASM 

IBM  PC  family 

PC  DOS 

Lattice  C 

OS9/68000  Portable 

various 

Assembler 

Sirius  1/Victor  9000 

MS-DOS 

C 

TRS-80  Model  4 

TRSDOS 

ASM 

Tandy  2000 

MS  DOS 

MASM 

TRS-80  I  and  III 

TRSDOS 

Z80  Ass. 

Minis  and  Mainframes  - 

Cray-1,  Cray-XMP 

CTSS 

Fortran-77 

Data  General 

AOS/ VS  with  MV/UX 

C 

DECSYSTEM-20 

TOPS -20 

MACRO-20 

Honeywell  6000 

DTSS 

Virtual  PL/ I 

Hewlett-Packard  3000 

MPE 

SPL 

IBM  370  Series 

VM/CMS 

Pascal/VS 

IBM  370  Series 

MTS 

Asm,  Pascal 

Assembler 

Sperry/Univac-1100 

EXEC 

VAX 

VMS 

C 

Figure  5.  Partial  list  of  available  KERMIT  applications 
C.  TERMINAL  EMULATOR 

There  are  many  types  and  makes  of  microcomputer  available  within  the  DOD 
community.  Creating  a  way  to  transport  graphic  images  among  all  of  them  would  in¬ 
volve  many  problems.  For  this  reason  the  selection  of  a  microcomputer  on  which 
to  base  the  emulation  program  is  a  critical  decision  point  in  this  thesis  research. 
This  choice  is  dictated  by  the  availability  and  cost  of  the  microcomputer  as  well  as  its 
resident  graphics  handling  capabilities.  Why  select  the  Heath/  Zenith  Z-100  over  the 
IBM-PC?  One  of  the  greatest  assets  of  the  Z-100  computer  is  its  high-resolution 
graphics  capability  which  is  made  easy  to  use  by  the  availability  of  powerful  graphics 
statements  in  the  Heath,  Zenith  (Z-BASIC)  implementation  of  .Microsoft  BASIC  [Ref 
13:  p.  77].  The  following  sections  provide  a  short  history  and  detailed  analysis  of  this 
decision. 


1.  Z-100  versus  IBM  PC 

The  IBM  Personal  Computer  (PC)  was  introduced  in  late  1981.  Because  of 
IB. M's  success  in  the  mainframe  market  place  and  the  fact  that  their  name  was  nearly 
synonymous  with  'computer',  it  took  the  microcomputer  world  by  storm  and  quickly 
became  the  industry  standard.  To  become  the  'standard'  was  an  important  devel¬ 
opment  in  the  then  new  marketplace.  The  biggest  change  it  introduced  was  the  idea 
of  third  party  software  development.  Until  then  almost  all  software  was  developed 
or  sponsored  for  development  by  each  computer  manufacturer  for  exclusive  use  with 
their  computer. 

The  fact  that  other  parties  could  now  write  and  produce  software  for  use 
on  a  set  of  new  standard  computers  was  both  a  blessing,  for  all  the  new  microcom¬ 
puters  that  were  to  come,  and  a  disaster  for  all  that  had  already  arrived.  IBM  had  done 
something  different  in  their  computer  architecture  that  made  it  vastly  different  [Ref. 
14:  p.  47]  from  nearly  all  previously  designed  computers  including  the  Z-100  . 

2.  Differences 

'The  biggest  differences  appear  in  the  physical  hardware  buss  structure,  the 
operating  system  and  read  only  memory  (ROM).  The  hardware  buss  that  IBM  se¬ 
lected  on  which  to  base  thier  PC's  equipment  architecture  was  not  compatible  with 
the  S-lOO  buss,  the  industry  standard.  This  means  that  the  physical  connections  are 
different  from  previous  hardware  implementations.  These  buss  differences  account 
for  most  of  the  hardware  incompatibility  while  the  ROM  is  to  blame  [Ref.  14:  p.  48] 
for  the  rest.  The  ROM  is  called  in  order  to  access  many  of  the  hardware  features 
required  to  accomplish  interfacing  between  the  software,  the  operating  system  and 
the  microcomputer. 

Even  a  relatively  simple  application  like  word  processing  requires  cursor 
movements  and  delete  funrtions  which  must  be  accessed  by  the  RO.M.  If  a  program 
goes  to  a  memory  location  expecting  to  find  an  instruction  and  finds  nothing  or, 
even  worse,  a  piece  of  data,  it  will  not  be  able  to  execute  the  correct  instruction.  This 
will  cause  the  program  to  stop.  Even  more  complicated  kinds  of  interface  problems 
arise  when  performing  graphics  functions  because  so  much  interaction  is  required 
between  screen  instructions,  memory  storage  and  system  functions  to  produce  screen 
images. 

The  actual  image  displayed  is  a  product  of  the  series  of  mapped  or  drawn  lines 
of  dots.  Each  dot  is  drawn  (turned  on  or  off)  on  the  screen.  The  number  of  dots 


available  to  turn  on  or  ofT  per  inch  are  the  picture  elements  (referred  to  as  a  pixels') 
and  the  higher  the  number  of  pixels,  the  higher  the  resolution  of  the  graphics.  The 
number  of  screen  pixels  addressable  are  characteristically  between  640  X  200  and  640 
X  400,  horizontally  and  vertically,  respectively.  All  the  difierent  pixel  combi¬ 
nations  and  sizes  require  different  aspect  ratio  (height  to  width)  calculations  in  order 
to  correctly  represent  graphic  images.  Beyond  these  complications,  within  each  system 
there  are  graphics  modes  (e.g.  low,  medium  high,  etc.)  which  correspond  to  different 
resolutions.  Different  microcomputer  systems  store  the  data  and  inlbrmation  required 
to  describe  the  picture  in  different  memory  locations,  which  adds  yet  one  more  level 
of  confusion.  From  this  brief  description  of  some  of  the  variables,  it  can  be  seen  that 
trying  to  write  one  software  program,  especially  a  graphics  intensive  one,  which 
would  apply  to  all  microcomputers  is  an  impossible  task. 

3.  Z- 1 00  Screen 

In  the  normal  text  mode,  the  Z-100  will  display  25  lines  of  text  at  80  characters 
per  line.  Each  character  is  comprised  of  a  matrix  of  8  X  9  pixels.  A  quick  and  simple 
calculation  leads  to  the  screen  resolution  of  640  (horizontal)  X  225  (vertical)  dots  which 
can  be  turned  on  or  off  to  draw  a  picture.  Although  too  complicated  to  address  in 
great  detail  in  this  thesis,  there  is  a  process  by  which  the  display  circuitry  in  the  Z-100 
can  address  the  pixels  to  provide  a  picture  400  lines  across,  instead  of  225.  This 
process  is  called  interlacing  because  every  other  line  is  displayed  in  an  alternating 
fashion.  The  price  payed  for  this  extra  resolution  is  a  flicker  apparent  to  the  human 
eye  in  tliis  mode.  Normally  the  screen  is  refreshed,  or  drawn  over,  60  times  every 
second.15  In  the  interlace  mode,  the  alternating  portions  of  the  screen  are  refreshed 
only  30  times  a  second,  which  can  be  seen  by  the  naked  eye.  This  gives  the  appearance 
of  "flickering '. 

4.  Tektronix  Screen 

The  interlace  mode  would  provide  a  much  better  quality  (higher  resolution) 
representation  of  the  actual  graphics  quality  if  using  that  mode  when  emulating  a 
Tektronix  graphics  terminal.  The  Tektronix  screen  format  is  a  1024  X  1024  pixel  in¬ 
struction  set,  but  the  rectangular  shape  of  the  cathode  ray  tube  (CRT)  reduces  the 
visual  area  to  a  1024  X  780  pixel  size.  There  are  other  differences  between  the  lo¬ 
cation  scheme  for  pixels  on  the  Tektronix  and  the  Z-100.  Figure  6  below  shows 

15  The  60  times  a  second  is  a  result  of  the  supply  power  of  60  Hz  (60  cycles  per  second). 
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there  is  also  a  dilTerence  in  the  orientation  of  the  screen's  home  or  (zero, zero)  starting 
point. 

The  CRT  graphics  can  be  routed  (saved)  to  a  disk  file  or  sent  directly  to  a  dot 
matrix  printer  [Ref.  14:  p.  73]  and  printed  with  nearly  the  same  resolution  as  the  ori¬ 
ginal  picture.  16  The  real  advantage  of  this  will  become  apparent  in  the  next  section 
about  the  printer  programs  . 

5.  Emulation  Program 

There  are  a  number  of  factors  which  must  be  discussed  in  order  to  attack 
the  problem  of  creating  a  program  which  would  display  graphic  information  on 
microcomputers.  The  major  factors  to  be  considered  are  the  language  to  use  in  program 
development,  the  type  of  data  used  to  describe/create  the  drawings,  the  format  and 
contents  ot  the  picture  data  file,  and  the  actual  drawing  program  itself  Each  of  these 
areas  is  further  examined  below. 

a.  Language  Selection 

The  advantage  of  using  a  high  level  and  more  structured  programming 
language  than  BASIC  is  that  it  would  perhaps  provide  an  easier  avenue  to  approach 
the  actual  program  coding.  But  built-in  graphics  statements  are  only  available  in  the 
PC-DOS  version  of  PASCAL,  and  there  are  only  a  few  libraries  of  graphics  subroutines 
available  for  C  which  are  only  for  the  IBM  [Ref  15:  p.  71].  BASIC,  on  the  other  hand, 
is  an  old  and  reliable,  if  not  omnipresent,  language  that  is  available  on  almost  all  gov¬ 
ernment-  owned  machines.  Using  BASIC's  built-in  graphics  statements  will  ensure  the 
program  will  run  on  all  of  the  target  microcomputers  an  i  can  be  easily  changed  as 
required  by  nearly  anyone  with  a  minimum  set  of  programming  skills. 

b.  Tektronix  Graphics  Protocol 

One  of  the  many  standard  graphics  formats  used  widely  is  the  Tektronix 
graphics  terminal  protocol.  The  high  performance  Tektronix  4010  series  terminals 
will  interface  with  many  host  graphics  processing  programs  such  as  SAS, GRAPH, 
TELL-A-GRAF,  GKS,  VANGO,  DI-3000,  PLOT-IO,  DISSPLA  and  many  more. 
There  are  commercial  emulation  software  packages  available  for  the  IBM  PC  which 
emulate  all  the  capabilities  of  the  4010  terminal  except  those  that  depend  on  the  storage 

16  A  common  standard  dot  matri.x  printer  like  the  OKIDATA  has  a  60  X  66  dot  per  inch 
printing  pattern.  When  printed  sideways  at  9.5"  x  6.5",  t.his  produces  an  area  print  of  627  X 
390  dots.  Recall  the  dot  per  inch  resolution  of  the  CRT  was  640  X  400  in  the  interleaving  mode. 
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Figure  6.  Diffeiences  between  the  Tektronix  and  Z-100  CRT. 

tube  technology',  n  These  emulator  programs  are  relatively  inexpensive,  but  require 
a  specific  hardware  upgradeis  to  enhance  the  normal  IBM  graphics  capability  to  a 
higher  resolution  range,  which  brings  it  closer  to  the  normal  resolution  capa¬ 
bilities  of  the  Z-100. 


1 7  The  storage  tube  technology  referred  to  are  the  write  thru  and  defocus  attributes  which 
are  activated  by  escape  sequence  instructions. 

IS  The  hardware  upgrades  required  are  the  Color  Graphics  Adapter  (CGA),  Enhanced 
Graphics  Adapter  (EGA)  or  other  graphics  enhancing  computer  hardware  upgrade. 
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c.  Drawing  Program 

Utilizing  the  built-in  graphics  capabilities  of  the  Z-100,  the  graphing 
protocol  of  the  Tektronix  terminal  can  be  emulated  using  the  drawing  instruction 
statements  in  Z-BASIC.  The  approach  is  outlined  in  these  five  steps; 

1.  Read  the  drawing  instruction  from  the  mainframe  or  other  other  graphics  source. 

2.  Calculate  the  equivalent  proportional  movement  on  the  Z-iOO  screen. 

3.  Draw  (turn  on  or  off)  each  vector  of  dot(s). 

4.  See  if  there  are  more  drawing  instructions  from  the  source  system. 

5.  Go  to  step  (1)  and  continue  until  finish  or  end  of  data  file, 

d.  Implementation 

The  emulator  program,  listed  in  Appendix  F  [Ref  13:  p.  80]  was  adapted 
easily  for  use  with  the  DDN.  The  playback  program,  also  listed  in  Appendix  F  and 
suggested  in  the  same  article,  allows  any  picture  to  be  saved  to  a  disk  file  from  the  main 
emulator  program  and  to  be  redrawn  to  the  CRT.  The  program  code  itself  is  very 
well  documented  and  a  very  detailed  discussion  of  the  program  can  be  obtained  from 
the  original  article  if  further  information  is  required.  The  emulator  can  be  adapted  to 
nearly  any  system  easily  with  only  slight  variation. 

e.  Capabilities 

The  emulation  program  was  selected  because  it  includes  only  the  minimum 
set  of  capabilities  required  to  complete  the  task  of  emulating  a  tektronix  graphics  ter¬ 
minal.  There  are  no  extras  to  cloud  the  major  emulation  issues  required  to  prove  the 
LO-CO-GRAF  system  concept.  The  basic  program  includes  a  communications  module 
which  allows  dialing  from  the  keyboard  if  using  an  auto  dial  modem.  The  graphics  data 
from  a  mainframe  processing  program  can  be  captured  (saved)  on  a  disk  on  the 
microcomputer  to  be  replayed/ displayed  onto  the  Z-  100  CRT. 

f.  Picture  Data  File 

After  the  graphics  source  program  is  accessed,  any  picture  screen  can 
be  savedl9  to  a  disk  in  about  50  kilobytes  of  disk  storage  space,  which  leaves  enough 
room  for  the  emulator  program,  the  playback  program  and  six  picture  files  on  a  disk 
formatted  with  360  K  of  storage.  The  advantage  of  this  method  of  storage  is  that  play¬ 
ing  back  the  picture  takes  a  ver>'  short  time  because  it  fills  the  video  memory  with  the 

19  This  process  is  actually  reading  each  screen  memory  address  and  copying  each  bvie  from 
memory  to  a  tile  named  by  the  operator,  thus  creating  a  picture  data  tile. 


data  and  does  not  have  to  redraw  the  picture  vector  by  vector.  With  the  picture  (e.g. 
map,  graph,  etc.)  redrawn  and  presented  on  the  CRT,  the  next  and  last  task  of  the 
LO-CO-GRAF  process  is  producing  a  paper  copy  for  use. 

D.  SCREEN  PRINTING 

Paper  copies  of  maps,  charts,  and  other  graphics  may  never  be  replaced  by  other 
media.  With  ail  the  computing  and  storage  power  available  today  there  is  still  a  reluc¬ 
tance  to  do  away  with  the  "file"  or  "working"  copy.  The  LO-CO-GR.AF  system  would 
not  be  complete  without  a  means  to  print  a  paper  copy  of  the  graphics  it  produces. 

Saving  the  frame^O  by  capturing  the  video  memoiy  of  the  CRT  to  a  disk  file  is 
the  heart  of  the  playback  and  screen  printing  function.  Recall  (para  Ill.C.o.c.)  the  de¬ 
cision  to  write  the  map  information  to  the  screen  and  then  save  it  as  a  pixel  by  pixel 
memory  dump,  '^’lis  process  maintains  the  best  possible  resolution  from  the  original 
vector  drawings  and  now  realizes  the  payoff  for  that  decision.  The  last,  and  now  easiest, 
task  for  the  system  is  to  simply  dump  the  screen  pixels  to  a  printer. 

There  are  many  screen  dump  programs  available  to  accomplish  this  but  the  one 
chosen  is  licensed  by  the  U.  S.  Government  and  applicable  to  many  standard  DOD 
printers. 

1.  SCDMP 

SCDMP  is  a  printing  utility  that  allows  reproduction  of  a  complete  video 
screen  on  a  dot  matrix  printer,  including  both  text  and  graphics,  without  having 
to  exit  the  current  program.  The  SCDMP  program  may  be  loaded  manually 
(by  entering  SCDMP  <  cr> )  or  automatically,  via 'autoexec.bat',  into  memory  at  the 
beginning  of  a  session  where  it  remains  resident  until  needed.  To  print  a  desired  sta¬ 
tionary  screen  or  frame,  simply  press  <SHIFT-F12>,  which  generates  an  interrupt-5 
and  activates  the  screen  aump. 

2.  Options 

The  SCDMP  program  allows  a  choice  of  which  color  bank  of  video  RAM  is 
dumped  (if  the  Z-100  has  all  banks  of  color  RA.M  installed).  The  number  of 
video  RAM  (VRAM)  banks  installed  in  the  computer  is  determined  automatically 
by  SCD.MP  upon  initial  load.  For  the  color  version,  entering  a  <B>  for  blue,  <R> 
for  red,  <G>  for  green,  or  <A>  for  all  banks  immediately  after  the 
<SHIFT-F12>  will  select  the  VRA.M  bank  to  be  printed.  If  no  character  is  entered. 


20  "Frame'  is  used  here  to  describe  the  graphic  and.  or  alphanumeric  contents  of  the  CRT 
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<  A>  U  banks  is  the  default.  If  only  one  bank  of  color  RA.M  is  installed,  only  the 
green  bank  can  be  dumped.  For  use  with  LO-CO-GRAF,  there  is  no  need  to  change 
from  the  default  since  only  the  green  bank  is  loaded  with  data  .Orom  any  saved  map. 
SCDMP  also  allows  multiple  density  printing  for  some  printers.  Entering  an  <  H  > 
immediately  after  the  <SHIFT-F12>  or  color  selection  would  cause  the  printer  to 
use  a  higher  density  mode  for  printing.  The  default  density  is  normal  or  standard 
density.  The  higher  density  switch  will  make  the  printout  much  darker.  There  are 
several  other  useful  switch  options  which  are  explained  in  more  detail  in  the  SCDMP 
documentation.^! 

3.  Printer  Support 

The  printers  currently  supported  for  U.  S.  Govermnent  use  are  the  Epson 
MX;RX,'FX  Series  with  Graftrax,  the  Okidata  Microline  83A,  and  Zenith, MPI 
99/150  Series.  A  dot  matrix  printer  which  is  compatible  with  any  of  these  may  also 
be  used.  Only  the  printer  control  instructions  need  be  the  same.  The  control  sequence 
information  can  be  determined  from  the  printer  operating  manual  [Ref  161.  Printing  a 
paper  copy  is  the  last  piece  of  the  LO-CO-GRAF  system.  The  next  step  is  to  put  it  all 
together  and  actually  create,  capture,  save,  playback,  and  print  a  map.  The  total  system 
will  be  evaluated  in  the  next  chapter  with  attention  given  to  any  problems  encountered. 


IV.  ANALYSIS  OF  DATA 


This  chapter  investigates  the  actual  steps  required  to  obtain  maps  in  a  typical 
session  using  the  Defense  Data  Network  and  provides  an  analysis  of  the  graphics  pro¬ 
ducts  produced  and  the  emulator  performance.  The  session  begins  with  accessing 
the  DDN  to  obtain  the  KER.MIT  files  necessary  to  establish  a  viable  communi¬ 
cations  network  and  ends  with  a  final  session  showing  how  to  use  that  network  to 
transmit  a  map  file. 

A.  OBTAIN  KERMIT 

The  best  way  to  show  how  the  system  works  is  to  use  it  to  promulgate  itself 
Assuming  only  a  knowledge  ot  the  system  components  and  some  basic  skills  operating 
microcomputers  and  any  DDN  terminal  it  is  possible  to  see  the  power  of 
LO-CO-GRAF  in  action. 

1.  The  DDN  Session 

The  following  session  on  the  DDN  is  a  demonstration  of  how  to  obtain  the 
KER.MIT  files  necessary  to  establish  a  working  communications  network  to  handle 
file  transfers  between  command  components  and  terminals.  The  first  step  is  to  locate 
a  DDN  terminal  and  sign  on  to  the  command's  account.  A  simple  File  Transfer  Pro¬ 
tocol  (FTP)  to  the  Columbia  University  Center  for  Computing  will  facilitate  down 
loading  all  the  necessary  files  to  get  KERMIT.  The  session  follows: 


*  The  star  (*)  below  will  indicate  notes  to  the  operator  and  provide  details  not 
otherwise  available  The  <cr>  will  be  used  to  indicate  carriage  return. 

*  Sign  on  to  the  DDN  to  get  the  welcome  message: 

WELCOME  TO  DDN.  FOR  OFFICIAL  USE  ONLY.  TAC  LOGIN  REQUIRED. 

CALL  NIC  1-800-235-3155  FOR  HELP. 

MONTRY  TAC  113  //:  61 
@0  3/103 

TAC  Userid:  XXXXX-XXXXX  *  Site  Specific 

Access  Code:  XXXXXX  *  Site  Specific 

Login  OK 

TCP  Trying.  .  .  Open 


ISI-SYSTEM-A,  TOPS-20  Monitor  6.1(4050) 

There  are  31+15  jobs  and  the  Load  Average  is 


THIS  SYSTEM  IS  RESTRICTED  TO  UNCLASSIFIED  INFORMATION  ONLY. 
THE  ENTRY  OR  COMMUNICATION  OF  CLASSIFIED  DATA  IS  PROHIBITED. 


After  login,  type  "HELP  ?"  followed  by  a  carriage  return  for 
a  list  of  on-line  help  topics. 


*  After  login  enter  the  following: 

@FTP  CU20B.C0LUMBIA.EDU 

*  The  system  responds  with: 

Connection  opened  (Assuming  TYPE  L  36,  MODE  S,  STRU  P) 

<  CU20B.COLUMBIA.EDU  FTP  Server  Process  5Z(46)-7 
at  Fri  15-Jan-88  12: 28-EST 

CU20B.  COLUMBIA.  EDU> 

*  Enter: 

LOGIN  ANONYMOUS  <cr> 

*  The  system  will  request  a  password: 

Password: 

*  Enter  GUEST  <  cr>  and  the  response  follows: 

<  User  ANONYMOUS  logged  in  at  Fri  15-Jan-88  12:  28-EST,  job  207. 
CU20B.  COLUMBIA.  EDU> 

*  At  this  point  request  access  to  the  KER.VIIT  disks  : 

CD  PK:<KERMIT>  <cr> 

*  The  response  will  be: 

<  Default  name  accepted.  Send  password  to  connect  to  it. 

CU20B.  COLUMBIA.  EDU> 

*  Now  enter  DIR  <  cr>  to  see  the  list  of  files  (it  is  very  long) 

DIR  <cr> 

<  List  started. 

PK: <KERMIT> 

AAAREAD.  ME. 6 
AAAUPD. HLP. 5 


AANETW.  HLF.  29  ^'^is  file  is  included  as  Appendix  D 


XXU.  C.  2 

CU20B.  COLUMBIA.  EDU> 

*  At  this  point  just  follow  the  instructions  in  appendix  C  and  D  to  obtain  the  correct 
files  and  KERMIT  is  now  in  your  DDN  account  for  the  Heath/Zenith  Z-100. 


*  to  quit  and  get  back  to  your  home  terminal  is  standard  procedure  from  here: 
Enter  BYE  <cr>: 
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BYE  <cr> 

<  QUIT  coaunand  received.  Goodbye. 

FTP>QUIT 

^LOGOUT 

Killed  Job  39,  User  BISHOPR,  TTY  162,  at  15-Jan-88  12:33:46 
Used  0:00:-08  in  0:07:54 
Host  closing  connection 
Closed 

2.  KERMIT  in  Hand 

With  a  usable  copy  of  KERMIT  on  site,  one  can  set  up  a  communications 
network  between  any  other  computer  that  has  a  copy  of  KERMIT.  As  can  be  seen  by 
the  simple  session  above,  there  are  virtually  no  problems  associated  with  obtaining  the 
necessary'  files  and  the  program  itself  is  self  documenting.  The  KERMIT  program  pro¬ 
vides  virtually  error  free  transmission  for  data  files  and  other  programs  between  com¬ 
puters. 

The  KERMIT  program  is  the  central  pivot  for  sending  not  only  the  map  data 
files  but  for  the  terminal  emulator,  play  back  and  printing  programs  which  make  up 
the  LO-CO-GRAF  system. 

B.  TERMINAL  EMULATOR 

Invoking  the  terminal  emulator  requires  entering  the  program  name  if  a  compiled 
version  is  available.  If  not,  then  an  interpreted  version  may  be  used  but  will  run  a  little 
slower.  To  invoke  an  uncompiled  version,  enter  Z-BASIC  and  then  the  program  name. 
After  loading  the  emulator  it  is  necessary  to  access  a  source  program  for  generating 
the  graphics  products.  For  this  portion  the  DON  was  again  chosen.  Using  the  Briefing 
Aid  System  (BAS)  on  the  DON  as  the  remote  source  provided  an  excellent  example 
of  the  networking  capability  of  the  LO-CO-GRAF  system. 

A  working  session  will  demonstrate  how  to  access  the  graphics  generating 
program  but  first  it  is  necessary  to  put  an  instruction  file  in  the  DON  directory  which 
identifies  the  type  of  terminal  used.22  Enter  and  name  a  file  that  will  reside  in  the  di¬ 
rectory  to  provide  connection  instructions  for  the  backend  device  protocol  in  the 
BAS.  This  file  name  will  be  requested  during  the  graphics  session.  The  data  must 

be  entered  as  follows: 

backend=(tektronlx) ,device=(d,tty:  ) 

After  the  file  is  created  on  the  DON  and  put  in  the  directory,  the  BAS  program  files 
can  be  used. 


22  Appendix  H  provides  specific  instruaion  for  accessing  the  DDN  with  a  Z-100  and  then 
using  the  LO-CO-GRAF  system. 


Figure  7.  Emulator  Screen 


1.  Emulator  Screen  Size 

After  accessing  the  DDN,  set  the  terminal  screen  size  to  24  lines  long.  This 
will  keep  it  from  killing  the  program  and  dumping  out  of  the  emulator  back  to  the  op¬ 
erating  system  on  the  Z-100.  The  problem  seems  to  stem  from  filling  the  screen  with 
data  or  alphanumerics  and  running  out  of  space.  When  running  the  emulator  this 
problem  can  be  avoided  by  clearing  the  screen  before  any  major  new  operation.  A 
preset  function  key  (F-4)  is  programmed  to  do  this  easily. 

2.  Emulator  Session 

After  invoking  the  emulator,  the  sign  on  the  screen,  as  showm  in  Figure  7,  ap¬ 
pears.  Clear  the  screen  before  continuing  and  enter  the  correct  codes  to  dial  the  DDN 

and  sign  on.  This  works  very  well  with  an  auto-  dial  modem  by  entering: 
ATDTXXXXXXX  *The  phone  number  varies  with  location 

The  next  step  was  to  access  the  program  in  the  following  manner: 

*  Again  signing  on  to  the  DDN 

WELCOME  TO  DDN.  FOR  OFFICIAL  USE  ONLY.  TAC  LOGIN  REQUIRED. 


*  After  complete  login  enter; 

@DIR<LEVEL2> 

PS:  <LEVEL2> 

2400-SLIDE.  GPX.  1 

AIRROUTES.  GPX.  1  *  This  slide  is  provided  as  example 

ETHIOPIAN-CONFLICT.  GPX.  1  *  Some  of  these  slides  are  provided 

FALKLAND- ISLANDS. GPX. 1  *  in  appendix  H 

HORMUZ.  GPX.  1 
MEDIT.  GPX.  1 

PACKET-RADIO-SLIDE.  GPX.  6 
RHORMUZ. GPX.  1 

*  Above  is  a  list  of  maps  available  to  be  downloaded  from  the  BAS  in  the  level2  direc¬ 
tory.  To  download  one  just  enter: 

<level2>Viewer  <cr> 

The  main  menu  will  appear  and  ask  for  the  name  of  the  device  instruction 
file23  and  then  which  map  to  generate.  An  c.xample  of  the  AIRROU TES.GPX  map 
is  in  Figure  8.  As  can  be  seen,  there  is  no  way  to  distinguish  between  the  two  colors 
that  indicate  the  two  routes.  This  is  not  a  problem  with  most  maps  because  a  single 
color  is  usually  all  that  is  available.  The  quality  is  comparable  to  a  similar  map 
generated  on  the  NFS  IB.M  mainframe  computer  using  DISSPLA's  World  Coast  Utili¬ 
ties  option. 

C.  MAP  QUALITY 

The  resolution  of  maps  currently  being  produced  electronically  is  sufficient  for  small 
scale,  large  area  planning.  These  maps  remain  highly  dependent  on  the  number  of  data 
points  available  for  generating  the  cartographic  projection.  Figures  9  and  10  represent 
typical  produas  of  mainframe  resident  mapping  programs.  The  differences  are  partially 
due  to  printer  capability;  Figure  9  being  produced  on  an  Epson-based  dot  matrix,  while 
Figure  10  was  done  on  IB.M  3800  laser  printer  capable  of  270  dpi.  These  maps  are  could 
be  ideal  for  strategic  and  operational  levels  of  command  and  staff  planning. 

23  This  is  the  file  placed  in  the  DON  directory  above. 


Figure  8.  Example  AIROUTES.GPX  Map 


1.  LO-CO-GRAF  and  Briefing  Aid  System  maps 

There  were  many  maps  to  choose  from  for  this  test  and  some  of  them  are  in 
Appendix  I  along  with  a  comparative  set  of  maps  generated  on  the  NTS  mainframe, 
which  are  included  at  Appendix  J.  The  maps  that  are  filled  in,  like  those  in  Figures  13 
through  15,  require  a  very  long  time  to  draw;  averaging  approximately  30  minutes  each. 
The  long  time  is  required  because  each  line  vector  must  be  calculated  and  drawm 


a 


scperately  to  fill  in  an  area.  Although  this  time  is  relatively  long,  it  is  not  an  unac¬ 
ceptable  period.  When  the  maps  were  saved  to  disk  and  played  back  later,  it  did  not 
make  a  difTcrence  in  redraw  times  whether  they  were  filled  in  or  not.  The  redraw  times 
were  very  fast,  three  to  sL\  seconds. 
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Figure  10.  Map  generated  by  DISSPLA  World  Coast  Utilities:  Area  map  of  the 
North  Sea  and  English  Channel  region. 

2.  DISSPLA  maps 

The  typical  map  generation  times  for  DISSPLA  was  seventy  seconds.  The  time 
for  a  metafile  to  generate  a  map  from  its  stored  data  was  thirty  seconds,  but  was  more 
dependent  on  system  loading.  The  longest  recall  time  for  a  metafile  was  210  seconds  in 
a  program  where  DISSPLA  used  many  of  its  self-correcting  features.  The  maps  would 
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be  suitable  for  strategic  and  operational  level  planners,  however  possible  tactical  uses 
are  negligible.  The  metafiles  transport  via  any  file  transfer  protocol  and  the  DISSPOP 
option  of  DISSPLA  can  display  them  on  an  extremely  wide  selection  of  graphics  devices. 
The  times  required  to  generate  these  maps  were  acceptable.  Better  cartographic  resol¬ 
ution  created  by  a  greater  number  of  data  points  could  increase  the  times  for  map  gen¬ 
eration,  but  this  probably  would  also  be  in  the  acceptable  range. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


The  premise  of  this  thesis  is  that;  (1)  access  to  maps  via  electronic  means  is  cur¬ 
rently  feasible  and  desirable,  and  (2)  combining  a  standard  dot  matrix  printer  with  the 
Z-100  microcomputer  (purchased  en  masse  between  1982  and  1986)  and  developing  a 
few  software  programs  which  could  provide  a  low  cost  graphics  and  map  generating  ca¬ 
pability  which  would  greatly  enhance  the  command  and  control  process.  These  premises 
were  achieved. 

A.  VALIDATION 

The  goal  of  this  thesis,  to  show  that  the  Zenith  Z-100  will  emulate  a  Tektronix 
graphics  terminal,  has  been  validated.  The  specific  C2  objective  of  electronically  trans¬ 
ferring  maps  and  charts  has  also  been  achieved.  Another  command  and  control  tool  has 
been  developed  which  can  be  further  exploited. 

1.  Large  Screen  Displays 

The  current  cartographic  representations  used  in  situation  rooms  and  command 
centers  for  their  large  screen  displays  lack  resolution.  The  preliminary  steps  have  been 
taken  in  this  thesis  to  make  maps  and  charts  available  at  the  desk  of  every'  microcom¬ 
puter  user  requiring  them.  The  benefits  are  significant  to  the  commander  and  decision 
makers,  intelligence,  logistics,  and  communications  personnel.  With  the  addition  of 
more  resources  and  research  to  microcomputer  graphics  emulation,  operationally  ori¬ 
ented  personnel  and  tactical  levels  of  command  will  soon  benefit  equally.  An  example 
of  this  is  the  current  maps  used  in  WWMCCS  displays  and  in  command  centers  which 
use  other  strategic  and  operational  level  cartographic  tools. 

2.  Simplicity 

A  self-imposed  requirement  to  attain  this  command  and  control  tool  at  no  cost 
has  been  achieved.  This  constraint  was  levied  in  order  to  make  it  accessible  to  all  DOD 
commands  as  soon  as  possible.  The  no-cost  alternative  for  having  a  local  graphics  ter¬ 
minal  capability  is  highly  desirable.  Many  commands  which  have  placed  their  Z-lOO's 
on  shelves,  in  storage,  or  marked  for  disposal  could  reconsider  that  decision.  The  variety 
of  graphics  products  which  can  be  displayed,  sent,  or  received  is  veiy  significant  and  will 
become  more  important  to  the  C2  process  in  the  future.  The  no-cost  decision  also  lim¬ 
ited  the  number  of  options  that  could  be  considered  to  software  already  purchased  by 
the  DOD  or  in  the  public  domain. 


B.  RECOMMENDATIONS  FOR  FUTURE  EFFORTS 

The  scope  of  this  project  was  sufficient  to  occupy  the  available  time.  It  did,  how¬ 
ever.  surface  many  future  areas  of  endeavor  to  be  e.\panded.  Below  are  listed  a  few  of 
the  interest  areas  uncovered; 

1.  User  Friendly 

The  requirement  to  be  more  user  friendly  will  surface  continuously  until  the 
machines  are  as  smart  as  people  are  and  will  do  what  is  required  without  being  told. 
Specific  areas  which  could  use  more  smoothing  arc:  (1)  Map  generating  packages  on 
mainframe  computers  operating  interactively,  requiring  only  page  or  screen  dimensions, 
level  of  resolution,  and  location  and  scale  of  the  map  or  chart,  and  (2)  the  graphics  ter¬ 
minal  emulator,  though  designed  to  be  friendly,  should  not  intimidate  the  user.  Selection 
of  devices  and  capabilities  should  be  menu  driven  and  include  error  and  fault  checking. 

2.  Applications  to  Tactical  Us  ;rs/«  .2  Centers 

Access  to  tactical  level  maps  and  charts  remains  the  real  requirement.  The  only 
centralized  source  of  this  cartographic  information  continues  to  be  DMA  and  NOAA. 
Therefore,  DMA  or  NOAA  must  devise  a  system  for  accessing  their  digitized  mapping 
databases  and  allowing  the  users  to  custom  build  their  own  maps  and  charts.  A  possible 
approach  to  solving  the  shortcoming  of  not  having  the  ability  to  transfer  maps  and 
charts  electronically,  would  be  to  develop  programs  for  many  microcomputers  to  con¬ 
struct  and  display  the  cartographic  plots.  The  microcomputer  would  need  to  have  a 
graphics  capability  sufficient  for  this  type  of  display.  The  example  of  maps  or  charts 
required  for  a  command  and  control  center  is  given  above.  A  more  significant  require¬ 
ment  is  the  ability  to  pass  tactical  level  maps.  Many  units  will  have  ready  brigades, 
specific  ships,  or  air  squadrons  in  an  alert  status.  When  these  units  are  required  to 
"fly-away",  they  possibly  may  not  have  gotten  to  the  point  on  the  logistics  checklist  for 
tactical  maps.  The  necessary  graphics  products  could  be  prepared  for  the  unit  and 
transmitted  to  it  while  in  transit.  Similarly,  intelligence  updates  and  other  information 
could  be  transmitted  as  soon  as  available. 

3.  NFS  Applications 

The  Naval  Postgraduate  School's  academic  program  has  many  uses  for 
cartographic  products.  For  example,  the  National  Security  Affairs  Department  uses 
some  of  the  microcomputer's  map  generation  programs  discussed  in  Chapter  I.  These 
are  used  for  strategic  level  discussions  and  as  aids  in  geographic  analysis.  The  .Admin¬ 
istrative  Sciences  Department  uses  similar  products  to  allow  graphical  analysis  of  sta- 


tistical  data.  The  >'eteorology  and  the  Air-Ocean  Science  Department  commonly  use 
the  map  generation  program  maintained  on  the  DEC  mainframe  computers  at  Fleet 
Numerical  and  Oceanographic  Center  across  tiie  highway.  The  biggest  user  of  maps  and 
charts  would  probably  be  the  Operations  R.esearch  Department,  specifically  the 
Wargaming  and  Analysis  Laboratory.  Their  current  system  uses  video  disc  technology 
to  display  maps  in  the  Joint  Theater  Level  System  (JTLS)  and  low  resolution  digitized 
maps  for  Naval  Warfare  Integrated  Simulation  SystemTntegrated  Battle  Group  Tactical 
Trainer  (NWISS/IBGTT). 

a.  Specific  Uses  for  DISSPLA  Maps 

One  suggested  area  for  further  study  is  the  generation  of  flat  earth  maps  to 
use  in  battle  planning  or  deployment  exercises.  These  maps  could  be  bounded  and 
sized  in  a  standard  way,  by  latitude  and  longitude,  so  that  they  could  be  cut  and 
pasted  to  e.xpand  as  operational  maneuvers  move  from  one  map  section  to  another. 
This  would  be  especially  useful  to  those  who  must  respond  to  crisis  situations  world 
wide  but  who  have  limited  knowledge  of  world  geography  or  no  access  to  existing 
maps. 

b.  Increased  use  of  DISSPOP 

The  ability  to  save  graphics  in  a  compressed  version,  a  metafile,  is  ver>’  sig’ 
nificant.  Preparation  by  students  or  instructors  could  be  made  readily  available  and  with 
little  specialized  training.  More  output  device  options  would  need  to  be  added  to  the 
current  DISSPOP  selection.  Examples  of  these  could  include  IB.M  PC's  with  CGA, 
EGA,  or  Hercules  upgrades  added  in.  Most  home  computers  with  a  significant  graphics 
capability  could  also  be  included. 

c.  NPS  War  Lab 

A  desirable  output  of  this  thesis  was  to  make  the  map  generation  program, 
and  the  Z-100  graphics  terminal  emulator,  portable  so  they  could  be  transferred  into  the 
Wargaming  Laboratory.  "The  communications  package  and  screen  dump  routines  would 
also  have  to  be  customized  to  equipment  existing  in  the  laboratory.  This  portion  was 
not  attempted  due  to  lack  of  time.  Significant  equipment  differences  exist  between  the 
wargaming  laboratory  and  the  main  computer  center  which  would  require  reworking  of 
all  phases  of  this  project.  A  partial  listing  of  the  necessary  changes  follows: 

1.  The  computer  center  uses  an  IBM  mainframe,  the  War  Lab  uses  a  V,-\X  computer. 

2.  DISSPLA  with  the  map  generation  option  is  maintained  on-line  with  the  computer 
center.  The  War  Lab  requires  that  advance  notice  be  provided  so  DISSPL.A,  and 
the  necessary  operating  environment  for  it,  can  be  scheduled. 


3.  The  map  generation  programs  and  its  interactive  version  are  written  in  VS  Fortran 
which  is  IBM  exclusive.  The  programs  would  need  to  be  modified  so  they  are 
compatible  with  Fortran  77  in  the  VAX  environment. 

4.  A  difierent  version  of  the  communications  program  (KERVIIT)  would  need  to  be 
employed.  As  the  discussion  in  Chapter  III  indicates,  the  version  of  KER.MIT  to 
talk  between  a  VAX  and  almost  any  microcomputer  is  available.  The  protocols 
remain  the  same,  which  is  the  reason  KERMIT,  in  particular,  was  chosen  for  use 
in  this  project. 

5.  The  screen  dump  program  chosen  for  this  project  was  designed  with  most  of  the 
industry  standard  printer  protocols  available.  The  correct  version  would  need  to 
be  chosen  for  the  printers  connected  to  the  Z-lOO's  in  the  War  Lab. 

d.  DOD  distributed  wargaming  system 

A  future  addition  to  the  NPS  War  Lab  is  a  connection  to  the  DOD  Dis¬ 
tributed  Network  (DISNET)  subnet  for  C3  research.  This  system  will  serve  NPS  and 
four  other  research  and  development  centers  and  engineering  activities.  Gateways  to 
other  classified  and  unclassified  capabilities  on  the  DDN  would  have  to  be  identified. 
The  opportunity  exists  with  this  system  to  have  available  more  expertise  and,  probably, 
a  greater  desire  to  access  high  resolution  digitized  maps  and  charts  or,  if  desired,  to  de¬ 
velop  tactical  ones  for  specific  circumstances.  The  use  of  electronically  transmitted  maps 
could  prove  to  be  valuable  research  in  the  C3  w'argaming  and  evaluation  networks. 
Research  conducted  to  aid  the  command  decision  maker  by  overiayed  maps  or  maps 
with  imbedded  symbology  could  also  be  conducted. 


APPENDIX  A.  EXAMPLE  PROGRAM  SHOWING  DISSPLA  S 
INTERACTIVE  MAPPING  CAPABILITY 


The  following  Fortran  program  uses  DISSPLA's  map  generation  option.  It  has 
been  written  to  be  user  friendly  and  “sailor-proor.  The  program  needs  to  be  performed 
at  a  graphics  workstation  which  includes  a  TEK  618.  In  order  to  run  this  program  on 
different  equipment,  some  modification  would  be  necessary. 

A.  HOW  TO  RUN  THE  DISSPLA  MAP  GENERATOR 

After  you  have  copied  the  following  program  you  can  generate  any  of  the  listed 
maps  at  any  time  you  wish: 

NOTE:  You  must  be  using  an  NFS  terminal  that  has  a  Tektronics  618 

graphics  monitor  attached. 

1.  Enter  "DISSPLA"  The  program  will  respond  with  a  welcome  message. 

2.  When  the  program  requests  the  name  of  the  program  you  wish  to  run,  enter  the 
file  name  you  have  given  this  program  and  then  press  "PF- 10/22"  to  execute. 
There  are  other  options  at  this  point  for  help  (PF-1, '13),  to  quit  (PF- 3/15),  or 
to  view  or  edit  a  map  file  (PF-4;  16). 

3.  After  pressing  the  PF-lO/22  key  (execute)  you  will  see  several  messages,  in¬ 
dicating  compiler  passes,  flash  across  the  screen.  This  will  be  followed  by  a  mes¬ 
sage  indicating  what  file  deffinitions  are  in  effect  and  asking  you  if  you  would  like 
to  execute  the  program  with  those  deffinitions  or  exit.  After  DISSPLA  calls 
up  all  the  supporting  programs,  you  will  be  asked  to  press  the  enter  key  to 
continue.  This  step  loads  the  Fortran  program  to  be  executed  and  compiles  it. 

4.  The  program  has  been  written  to  guide  you  through  the  selection  of  a  map  to 
plot  and  plot  it  for  you.  You  will  then  be  asked  to  enter  the  name  of  the  map  you 
have  chosen.  As  the  data  for  the  map  is  called  from  disk  storage  you  will  see 
the  plot  being  generated  on  the  TEK-618.  After  the  map  is  plotted  on  the 
graphics  monitor,  you  will  receive  a  prompt  on  the  IB. VI  terminal  monitor  in¬ 
structing  you  to  press  "enter"  to  continue.  If  you  want  a  hard  copy  of  the  map,  you 
can  press  the  HARD  COPY  button  on  the  bottom  of  the  graphics  monitor  first. 

B.  INTERACTIVE  MAP  GENERATION  FORTRAN  PROGRAM 


C*  "THE  POWER  OF  DISSPLA's  MAP  PROsJECTION  OPTION"  *  MAP0003C 
C*  *  MAPOOOAG 
C*  BRETTE  WALKER  *  MAPOOOSCi 
C*  GENE  BISHOP  *  MAP00060 
C*  ROB  SABO  *  MAP00070 

**yr******'***yrVr*************'A-*-******'fr*Vr  0008/' 


INITIALIZE 

INTEGER  CHOICE,  ANSWER 
CHOICE  =  0 
ANSWER  =  0 


WRITE  (6,10) 

FORMAT  ('  THIS  PROGRAM  DEMONSTRATES  THE  MAP  GENERATION  ' ,/ 

1'  CAPABILITY  OPTION  OF  THE  DISSPLA  PROGRAM.  ') 

WRITE  (6,20) 

FORMAT  ( '  CERTAIN  MAPS  HAVE  BEEN  PREPROGRAMMED  INTO  THIS  ' , / 

1'  DEMONSTRATION  AND  ARE  AVAILABLE  FOR  YOUR  VIEWING  ONLY  ',/ 

2'  ON  THE  TEK618  DISPLAY.  ') 

WRITE  (6,30) 

FORMAT  ( ^  PLEASE  SELECT  FROM  THE  MENU  BELOW  THE  EXAMPLE  MAP  ' , / 
1'  YOU  WOULD  LIKE  TO  VIEW. ') 


WRITE  (6,40) 
FORMAT  (^ 


MENU') 


WRITE  (6,50) 

FORMAT  ( '  1.  NORTH  AND  SOUTH  AMERICA.  ' ) 
WRITE  (6,60) 

FORMAT  ( '  2.  CARIBBEAN  AREA.  ’ ) 

WRITE  (6,70) 

FORMAT  C  3.  NORTHERN  FLANK.  ' ) 

WRITE  (6,80) 

FORMAT  ( '  4.  MEDITERRANEAN  AREA. ' ) 


WRITE  (6,90) 
FORMAT  ('  5. 
TOITE  (6,92) 
FORMAT  ('  C. 


JAPAN  AREA.  ' ) 


92  FORMAT  ('  6.  QUIT.  ') 

WRITE  (6,100) 

100  FORMAT  ('  PLEASE  ENTER  YOUR  CHOICE:  1,2, 3, 4, 5  OR  6.') 

READ  *, CHOICE 
C 

C  ERROR  CHECK  OF  CHOICE 
C 

C  IF  THE  CHOICE  IS  ONE  OF  THE  ALLOWABLE  CHOICES  THEN  CONTINUE 
IF  (CHOICE.  GT.O.  AND.  CHOICE.lt.  7)  GO  TO  110 

C  ELSE  IF  AN  ERRONEOUS  CHOICE  THEN  REENTER  CORRECT  CHOICE 
WRITE  (6,105) 

105  FORMAT  ( ’  YOU  HAVE  MADE  AN  INCORRECT  ENTRY. ' ) 

GO  TO  25 
C 

C  CONTINUE 

110  IF  (CHOICE. EQ.  1)  CALL  NSAMER 
IF  (CHOICE. EQ.  2)  CALL  CARMAP 
IF  (CHOICE. EQ. 3)  CALL  NORMAP 
IF  (CHOICE.  EQ.  4)  CALL  MEDMAP 
IF  (CHOICE.  EQ.  5)  CALL  JAPMAP 
IF  (CHOICE.  EQ.  6)  GO  TO  145 
C 

C  TRY  AGAIN? 

WRITE  (6,120) 

120  FORMAT  (  '  WOULD  YOU  LIKT:  TO  TRY  AGAIN? '  ) 


MAPOOlOO 

MAPOOllO 

MAP00120 

MAP00130 

MAP00140 

MAP00150 

MAP00160 

MAP00170 

MAP00180 

MAP00190 

MAP00200 

MAP00210 

MAP00220 

MAP00230 

MAP00240 

MAP00250 

MAP00260 

MAP00270 

MAP00280 

MAP00290 

MAP00300 

MAP00310 

MAP00320 

MAP00330 

MAP00340 

MAP00350 

MAP00360 

MAP00370 

MAP00380 

MAP00390 

MAP00400 

MAP00410 

MAP00420 

MAP00430 

MAP00440 

MAP00450 

MAP00460 

MAP00470 

MAP00480 

MAP00490 

MAP00500 

MAP00510 

MAP00520 

MAP00530 

MAP00540 

MAP00550 

MAP00560 

MAP00570 

MAP00580 

MAP00590 

MAP00600 

MAP00610 

MAP00620 

MAP00630 

MAP00640 

MAP00650 


UOCJU^OCJ<-H>-H  UOOCJO  CJUO  OOOU  UOOO  UCJUO  uuo 


1 


125  WRITE  (6.130) 

130  FORMAT  ( '  ENTER  1  FOR  YES  OR  2  FOR  NO.  ' ) 
READ  *, ANSWER 
C 

C  CHECKING  INPUT  FOR  ERROR 

IF  (ANSWER. GT. 0.  AND.  ANSWER.  LT.  3)  GO  TO  140 


135 


WRITE  (6,135) 

FORMAT  ( '  YOU  HAVE  MADE  AN  INCORRECT  ENTRY.  ’ ) 


GO  TO  125 
CONTINUE  BY  CHECKING  FOR  YES  OR  NO 
CHECK  FOR  YES 

40  IF  (ANSWER.  EQ.  1)  GO  TO  25 

ELSE  ANSWER  IS  NO  AND  PROGRAM  IS  EXITED 
45  WRITE  (6,150) 

50  FORMAT  ( '  HAVE  A  NICE  DAY. ' ) 

STOP 

END 


SUBROUTINE  FOR  MAP  OF  NORTH  &  SOUTH  AMERICA 

THIS  SUBROUTINE  WILL  CREATE  A  MAP  OF  NORTH  &  SOUTH  AMERICA  INCLUDING 
CENTRAL  AMERICA,  HAWAII,  AND  THE  CARRIBEAN 

SUBROUTINE  NSAMER 
LEVEL  0 

CALL  GRAPHICS  DEVICE 

CALL  TEK618 

CALL  HWSCAL  (’SCREEN') 


LEVEL  1 


SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 


A=ll 

CALL  PAGE  (A, 8,  5) 

CALL  PROJCT  CMERCA') 

CALL  MAPOLE  (-120,  0.  ) 

CALL  AREA2D  (10,8) 

LEVEL  2 

DEFINE  MAP  PARAMETERS 
CALL  MAPGR  (-180.  ,30.  ,10. ,-55. ,30. ,75. ) 

LEVEL  3 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 
CALL  MAPFIL  ('COAS') 

RETURN  TO  LEVEL  2 
CALL  ENDPL(O) 

RETURN 


MAP00660 

MAP00670 

MAP00680 

MAP00690 

MAP00700 

MAP00710 

MAP00720 

MAP00730 

MAP00740 

MAP00750 

MAP00760 

MAP00770 

MAP00780 

.MAPOOJgO 

MAP00800 

MAP00810 

MAP00820 

MAP00830 

MAP00840 

MAP00850 

MAP00880 

MAP00890 

MAP00900 

MAP00910 

MAP00920 

MAP00930 

MAP00940 

MAP00950 

MAP00960 

MAP00970 

MAP00980 

MAP00990 

MAPOIOOO 

MAPOlOir 

MAP0102C 

MAP0103(i 

MAP01040 

MAP01050 

MAP01060 

MAP01070 

MAP0108G 

MAP01090 

MAPOllOO 

MAPOlllO 

MAP0112(. 

MAP0113(! 

MAP01140 

MAP0115C 

MAP0116( 

MAPOllVi 

MAP01181 

MAP01190 

MAP01200 

MAP01210 

MAP01220 

MAP012'-i 


onoo  o  Cl  n  Cl  Cl  ci  ci  ci  a  ooon  oooo  oonoooorjn 


END 

C . 

SUBROUTINE  NORMAP 

THIS  IS  THE  NORTHERN  FLANK  OF  NATO 

THIS  PROGRAM  WILL  GENERATE  A  THEATER  LEVEL  MAP  OF  THE  NORTHERN 
FLANK  AND  INCLUDES  ALL  THE  SCANDINAVIAN  COUNTRIES. 

LEVEL  0 

CALL  GRAPHICS  DEVICE 
CALL  TEK618 

LEVEL  1 

SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 

CALL  PAGE(15.  ,11.  ) 

CALL  SCMPLX 
CALL  PROJCTC 'MERCA' ) 

CALL  MAPMDEC 'STRAI' ) 

CALL  AREA2D(13.  ,9.  ) 

CALL  XNAMEC '  ' ,1) 

CALL  YNAMEC  ',!) 

CALL  XAXANGCO. ) 

CALL  HEADIN( 'NORTHERN  FLANK  OF  NATO' ,22 , 1.  5 , 1) 

LEVEL  2 

DEFINE  MAP  PARAMETERS 
CALL  MAPGR(-15.  ,5.  ,55. ,55. ,5. ,75. ) 

LEVEL  3 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 

CALL  MAPFIL('PEUR') 

CALL  MAPFIL('EURO') 

CALL  MAPFILC 'ASIA' ) 

CALL  MAPFILC 'PASI' ) 

CALL  FRAME 
CALL  DASH 
CALL  GRIDCl.l) 

CALL  MARKER(-l) 

RETURN  TO  LEVEL  2 

CALL  ENDPL(O) 

RETURN 
END 


SUBROUTINE  JAPMAP 

THIS  IS  A  MAP  OF  THE  OPERATING  AREAS  AROUND  JAPAN 

THIS  PROGRAM  WILL  GENERATE  A  THEATER  LEVEL  MAP  OF  THE  SEA  OF 
JAPAN. 


MAP01240 

MAP01270 

MAP01280 

MAP01290 

MAP01300 

MAP01310 

MAP01320 

MAP01330 

MAP01340 

MAP01350 

MAP01360 

MAP01370 

MAP01380 

MAP01390 

MAP01400 

.MAP01410 

MAP01420 

MAP01430 

MAP01440 

MAP01450 

MAP01460 

MAP01470 

MAP01480 

MAP01490 

MAP01500 

MAP01510 

MAP01520 

MAP01530 

MAP01540 

MAP01550 

MAP01560 

MAP01570 

MAP01580 

MAP01590 

MAP01600 

MAP01610 

MAP01620 

MAP01630 

MAP01640 

MAP01650 

MAP01660 

MAF01670 

MAP01680 

MAP01690 

MAP01700 

MAP01710 

MAP01720 

MAP01730 

MAP01740 

MAP01750 

MAP01780 

MAP01790 

MAP01800 

MAP01810 

MAP01820 

MAP01830 
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c 

MAP01840 

c 

LEVEL  0 

MAP01850 

c 

CALL  GRAPHICS  DEVICE 

MAP01860 

c 

.MAP01870 

CALL  TEK618 

MAP01880 

c 

MAP01890 

c 

LEVEL  1 

MAP01900 

c 

SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 

MAP01910 

c 

MAP01920 

CALL  PAGE(15. ,11. ) 

MAP01930 

CALL  SCMPLX 

MAP01940 

CALL  PROJCT('MERCA') 

MAP01950 

CALL  M^PMDEC ' STRAI ' ) 

MAP01960 

CALL  AREA2D( 13. ,9. ) 

MAP01970 

CALLXNAMEC  ',1) 

MAP01980 

CALLYNAMEC  ',1) 

MAP01990 

CALL  XAXANG(0. ) 

MAP02000 

CALL  HEADINC ' JAPAN  AND  THE  KURILE  ISLANDS 28 , 1. 5 , 1) 

MAP02010 

c 

M.4P02020 

c 

LEVEL  2 

MAP02030 

c 

DEFINE  .MAP  PARAMETERS 

MAP02040 

c 

MAP02050 

CALL  MAPGR(125.  ,5.  ,160. ,30.  ,5.  ,55.  ) 

MAP02060 

c 

MAP02070 

c 

LEVEL  3 

MAP02080 

c 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 

MAP02090 

c 

MAP02100 

CALL  MAPFILC 'ASIA' ) 

MAP02110 

CALL  MAPFILC 'PASI') 

MAP02120 

CALL  FRAME 

MAP02130 

CALL  DASH 

MAP02140 

CALL  GRIDCl.l) 

MAP02150 

CALL  MARKER(-l) 

MAP02160 

c 

MAP02170 

c 

RETURN  TO  LEVEL  2 

MAP0218r. 

c 

MAP0219C 

CALL  ENDPL(O) 

MAP02200 

c 

MAP02210 

RETURN 

HAP02220 

END 

MAP02230 

p--. 

"•••  aArUZZOU 

SUBROUTINE  MEDMAP 

MAP0227C 

c 

MAP0228n 

c 

THIS  PROGRAM  WILL  GENERATE  A  THEATER  LEVEL  MAP  OF  THE 

MAP02290 

c 

MEDITERRANEAN  SEA. 

MAP0230C 

c 

LEVEL  0 

MAP0234C; 

c 

CALL  GRAPHICS  DEVICE 

MAP02350 

c 

MAP0236C' 

CALL  TEK618 

MAP0237( 

c 

MAP0238C 

c 

LEVEL  1 

MAP0239'. 

c 

SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 

MAP0240f 

c 

MAP024K; 

CALL  PAGE(15.  ,11.  ) 

MAP02420 

CALL  SCMPLX 

MAP02430 

CALL  PROJCTC 'MERCA' ) 

MAP0244' 

49 
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CALL  MAPMDEC 'STRAI' ) 

CALL  AREA2D(13.  ,9.  ) 

CALLXNAMEC  ’,1) 

CALL  YNAMEC '  ’ ,1) 

CALL  XAXANGCO.  ) 

CALL  HE AD IN( 'MEDITERRANEAN  SEA' , 17 , 1. 5 , 1) 

LEVEL  2 

DEFINE  MAP  PARAMETERS 
CALL  MAPGR(-10.  ,5.  ,40.  ,25.  ,5.  ,50. ) 

LEVEL  3 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEV'LL  OF  RESOLLTION 

CALL  MAPFILC 'PEUR' ) 

CALL  MAPFILC 'EURO' ) 

CALL  MAPFILC 'ASIA' ) 

CALL  MAPFILC 'PASI' ) 

MAPFILC  'PAFR'  ) 

CALL  MAPFILC 'AFRI' ) 

CALL  FRAME 
CALL  DASH 
CALL  GRIDCl.l) 

CALL  MARKERC-1) 

RETURN  TO  LEVEL  2 

CALL  ENDPLCO) 

RETURN 

END 


SUBROUTINE  CARMAP 

THIS  IS  A  MAP  OF  THE  CARRIBEAN  OPERATING  AREAS 

THIS  PROGRAM  WILL  GENERATE  A  THEATER  LEVEL  MAP  OF  THE  CARIBBEAN 
SEA  AND  THE  GULF  OF  MEXICO.  ALL  OF  CENTRAL  AMERICA  IS  INCLUDED. 

LEVEL  0 

CALL  GRAPHICS  DEVICE 
CALL  TEK618 

LEVEL  1 

SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 

CALL  PAGEC15.  ,11.  ) 

CALL  SCMPLX 

CALL  PROJCTC'MERCA') 

CALL  MAPMDEC 'STRAI' ) 

CALL  AREA2DC13.  .9.  ) 

CALLXNAMEC'  ',1 
CALL  YNAMEC'  ’,1) 

CALL  XAXANGCO.  ) 


MAP02450 

MAP02460 

MAP02470 

MAP02480 

MAP02490 

MAP02500 

.MAP02510 

MAP02520 

MAP02530 

MAP02540 

MAP02550 

MAP02560 

MAP025:0 

MAP02580 

.MAP02590 

MAP02600 

MAF02610 

MAP02620 

MAP02630 

MAP02640 

MAP02650 

MAP02660 

MAP02670 

MAP02680 

MAP02690 

MAP02700 

MAP02710 

MAP02720 

MAP02730 

MAP02740 

MAP02750 

MAP02760 

MAP02800 

MAP02810 

MAP02820 

MAP02830 

MAP02840 

MAP02850 

MAP02860 

MAP02870 

MAP02880 

MAP02890 

MAP02900 

MAP02910 

MAP02920 

MAP02930 

MAP02940 

MAP02950 

MAP02960 

MAP02970 

MAP02980 

MAP02990 

MAP03000 

MAP03010 

MAP03020 

MAP03030 


non  oooo  oooo 


CALL  HEADINC ' CARIBBEAN  SEA' , 13, 1. 5 , 1) 

MAP03040 

.MAP03050 

LEVEL  2 

MAP03060 

DEFINE  MAP  PARAMETERS 

MAP03070 

MAP03080 

CALL  MAPGR(-100.  ,5.  ,-60.  ,5.  ,5.  ,35. ) 

W03090 

MAP03100 

LEVEL  3 

MAP03110 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 

MAP03120 

MAP03130 

CALL  MAPFIL('PNOR') 

MAP03140 

CALL  MAPFILC 'NORT' ) 

CALL  MAPFILC 'PSOU' ) 

CALL  .MAPFILC 'SOUT' ) 

MAP03150 

M.4P03160 

MAP03170 

CALL  FRAME 

MAP03180 

CALL  DASH 

.MAP03190 

CALL  GRIDCl.l) 

MAP03200 

CALL  MARKERC-1) 

MAP03210 

MAP03220 

RETURN  TO  LEVEL  2 

MAP03230 

MAP03240 

CALL  ENDPLCO) 

MAP03250 

MAP03260 

RETURN 

MAP03270 

END 

MAP03280 

APPENDIX  B.  DISSPLA  MAP  GENERATION  PROGRAMS 


The  following  Fortran  programs  can  be  used  by  DISSPLA  to  generate  maps.  Some 
modification  could  be  necessary  in  order  to  ensure  compatibility  to  the  mainframe  and 
graphics  terminals  they  would  be  run  on.  As  written,  they  were  developed  using  VS 
Fortran.  The  version  of  DISSPL.A  being  used  must  include  the  World  Coast  Utilities 
Option  and  the  DISSPOP  option  which  causes  compression  and  decompression  of  the 
map  files.  Table  2  lists  the  maps  that  can  be  generated  by  the  VS  Fonran,  DISSPLA 
programs  and  the  pages  they  can  be  found  on. 


Table  2.  GUIDE  TO  DISSPLA  MAPPING  PROGRAMS 


.VI  ap  description 

Page 

Carribean  Operating  Area 

53 

Northern  Flank  of  NATO 

54 

North  and  South  America 

55 

Washington.  DC 

56 

World  .Mercator  Projection 

57 

Cape  Canaveral,' Kennedy  Space  Center 

59 

Japan  and  the  Kurile  Islands 

60 

Mediterranean  Operating  Area 

61 

North-West  Europe 

62 

'4 

y 

51 
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I 
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THIS  IS  A  MAP  OF  THE  CARRIBEAN  OPERATING  AREAS 


THIS  PROGRAM  WILL  GENERATE  A  THEATER  LEVEL  MAP  OF  THE  CARIBBEAN 
SEA  AND  THE  GULF  OF  MEXICO.  ALL  OF  CENTRAL  AMERICA  IS  I.VCLUDED. 


LEVEL  0 

CALL  GRAPHICS  DEVICE 


CALL  COMPRS 


LEVEL  1 

SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 


CALL  PAGE(15. ,11. ) 

CALL  SCMPLX 

CALL  PROJCTC 'MERCA' ) 

CALL  MAPMDEC 'STRAI' ) 

CALL  AREA2D(13.  ,9.  ) 

CALLXNAMEC  ',!) 

CALLYNAMEC  ',!) 

CALL  XAXANGCO. ) 

CALL  HEADINC ' CARIBBEAN  SEA* ,13,1.  5,1) 


LEVEL  2 

DEFINE  MAP  PARAMETERS 


CALL  MAPGR(-100.  ,5.  ,-60.  ,5.  ,5. ,35. ) 


LEVEL  3 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 


CALL  MAPFIL('PNOR') 
CALL  MAPFIL('NORT') 
CALL  MAPFIL('PSOU') 
CALL  MAPFIL('SOUT') 
CALL  FRAME 
CALL  DASH 
CALL  GRIDd.l) 

CALL  MARKER(-l) 


RETURN  TO  LEVELS  2,  1,  AND  0 


CALL  ENDPL(O) 
CALL  DONEPL 
STOP 
END 


V  ’fc**  *1/  * 


CAR00030 
CAR00040 
CAR00050 
CAR00060 
CAR00070 
CAR00080 
CAR00090 
CAROOlOO 
CAROOllO 
CARGO  120 
CAR00130 
CAR00140 
CARGO 150 
CAR00160 
CAR00170 
CAR00180 
CAR00190 
CAR00200 
CAR00210 
CAR00220 
CAR00230 
CAR00240 
CAR00250 
CAR00260 
CAR00270 
CAR00280 
CAR00290 
CAR00300 
CAR00310 
CAR00320 
CAR00330 
CAR00340 
CAR00350 
CARGO'-'';' 
CAR003 '0 
CAR00380 
CAR00390 
CAR00400 
CAR00410 
CAR00420 
CAR00430 
CAR00440 
CAROO^iSO 
CAR00460 
CAR004/(' 
CARO 04 80 


o  n  n  noon  noon  o  o  <n  o  o  o  o  o  n  o  o  n 


THIS  IS  THE  NORTHERN  FLANK  OF  NATO 

THIS  PROGRAM  WILL  GENERATE  A  THEATER  LEVLL  MAP  OF  THE  NORTHERN 
FLANK  AND  INCLUDES  ALL  THE  SCANDINAVIAN  COUNTRIES. 

LEVEL  0 

CALL  GRAPHICS  DEVICE 
CALL  COMPRS 

LEVEL  1 

SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 

CALL  PAGE(15.  ,11.  ) 

CALL  SCMPLX 

CALL  PROJCTC 'MERCA' ) 

CALL  MAPMDEC 'STRAI' ) 

CALL  AREA2D(13.  ,9.  ) 

CALLXNAMEC  ’,1) 

CALL  YNAxMEC  ',!) 

CALL  XAXANGCO.  ) 

CALL  HE AD IN( 'NORTHERN  FLANK  OF  NATO’ ,22, 1.  5 , 1) 

LEVEL  2 

DEFINE  MAP  PARAMETERS 
CALL  MAPGR(-15.  ,5.  ,55.  ,55.  ,5.  ,75.  ) 

LEVEL  3 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 

CALL  MAPFIL('PEUR’) 

CALL  MAPFIL('EURO') 

CALL  MAPFIL('ASIA') 

CALL  MAPFILC 'PASI' ) 

CALL  FRAME 
CALL  DASH 
CALL  GRID(1,1) 

CALL  MARKER(-l) 

RETURN  TO  LEVELS  2,  1,  AND  0 

CALL  ENDPL(O) 

CALL  DONEPL 

STOP 

END 


NOROOOlO 

N0R00020 

N0R00030 

.NOR00040 

.N0R00050 

N0R00060 

N0R00070 

N0R00080 

N0R00090 

NOROOlOO 

NOROOllO 

NOR00120 

NC.R00130 

NOROOi/.0 

\OR00150 

NOR00160 

.NOR00170 

NOxROOiaO 

NOR00190 

NOR00200 

NOR00210 

xNOR00220 

NOR00230 

N0R00240 

N0R00250 

xNOR00260 

NOR00270 

NOR00280 

N0R00290 

NOR00300- 

x\0R00310 

NOR00320 

NOR00330 

N0R00340‘ 

N0R00350 

NOR00360 

NOR00370 

N0R00380 

N'OR00390 

NOR00400 

NOR00410 

NOR00420 

NOR00430 

N0R00440 

NOR00450 

NOR00460 


n  rj  n  ana  non  noon  n  n  o  o  oooo  o  o  o  o  o  o 


THIS  PROGRAM  WILL  CREATE  A  MAP  OF  NORTH  &  SOLTH  AMERICA  INCLUDING 
CENTRAL  AMERICA,  HAWAII,  AND  THE  CARRIBEAN 

LEVEL  0 

CALL  GRAPHICS  DEVICE 

CALL  COMPRS 

CALL  HWSCAL  ( ' SCREEN' ) 

LEVEL  1 

SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 

A=ll 

CALL  PAGE  (A, 8. 5) 

GALL  PROJCT  ('MERCA') 

CALL  MAPOLE  (-120,  0.  ) 

CALL  AREA2D  (10,8) 

LEVEL  2 

DEFINE  MAP  PARAMETERS 
CALL  MAPGR  (-180.  ,30.  ,10.  ,-S5.  ,30.  ,75. ) 

LEVEL  3 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 

CALL  MAPFIL  ('COAS') 

RETURN  TO  LEVEL  2 

CALL  ENDPL(O) 

RETURN  TO  LEVEL  1 

CALL  DONEPL 

RETURN  TO  LEVEL  0 

STOP 

END 


NSAOOOlO 

NSA00020 

NSA00030 

NSA00040 

NSA00050 

NSA00060 

NSA00070 

NSA00080 

NSA00090 

NSAOOlOO 

NSAOOllO 

\'SA00120 

N'SAOOIjO 

NSA00140 

NSA00150 

NSA00160 

NSA00170 

NSA00180 

NSA00190 

NSAC0200 

NSA00210 

NSA00220 

NSA00230 

NSA00240 

NSA00250 

NSA00260 

NSA00270 

NSA00230 

N'SA00290 

NSA00300 

NSA00310 

NSA00320 

NSA00330 

NSAOO" 

NSA003  .0 

NSA00360 

NSA00370 

NSA00380 

NSA00390 

NSAOOAOO 


ooo  on  non  noon  noon  oooo  oooonooo 


THIS  IS  A  MAP  GENERATED  TO  COMPARE  RESOLUTION  BET^EN  DISSPLA 
GENERATED  MAPS  AND  OTHER  DIGITIZED  MAPPING  PROGRAMS. 

THIS  IS  A  .MAP  OF  THE  WASHINGTON  DC  AREA 

LEVEL  0 

CALL  GRAPHICS  DEVICE 
CALL  COMPRS 

LEVEL  1 

SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 

CALL  PAGE(8.  5,11.  ) 

CALL  SCMPLX 

CALL  PROJCTC 'MERCA' ) 

CALL  MAPMDEC 'STRAI' ) 

CALL  AREA2D(6.  ,3.  ) 

CALLXNAMEC  ',!) 

CALLYNAMEC  ',!) 

CALL  XAXANG(0.  ) 

CALL  HEADINC 'WASHINGTON  DC  AREA' , 18 , 1.  5 , 1) 

LEVEL  2 

DEFINE  MAP  PARAMETERS 
CALL  MAPGR(-78.  ,0. 5,-76. ,38. ,0.5,40. ) 

LEVEL  3 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 

CALL  MAPFIL(’PNOR') 

CALL  MAPFIL('NORT') 

CALL  MAPFILC 'USAH' ) 

CALL  FRAME 
CALL  DASH 
CALL  GRID(1,1) 

CALL  MARKER(-l) 

RETURN  TO  LEVEL  2 

CALL  ENDPL(O) 

RETURN  TO  LEVEL  1 
CALL  DONEPL 

RETURN  TO  LEVEL  0 

STOP 

END 


DCMOOOlO 

DCM00020 

DCM00030 

DCM00040 

DCM00050  ' 

DCM00060 

DCM00070 

DCM00080 

DCM00090 

DCMOOlOO 

DCMOOllO 

DCM00120 

DCM00120 

DCM00140 

DCM00150 

DCM00160 

DCM00170 

DCM00180 

DCM00190 

DCM002C0 

DCM00210 

DCM00220 

DCM00230 

DCM00240 

DCM00250 

DCM00260 

DCM00270 

DCM00280 

DCM00290 

DCM00300 

DCM00310 

DCM00320 

DCM00330 

DCM0034a 

DCM00350 

DCM00360 

DCM00370 

DCM00380 

DCM00390 

DCM00400 

DCM00410 

DCM00420 

DCM00430 

DCM00440 

DCM00450 

DCM00460 

DCM00470 

DCM00480 

DCM00490 

DCM00500 


The  following  program  will  generate  a  world  map. 

DIMENSION  DAT(72,46),RHITE(72,46) 

COMMON  WORKCSOOO) 

CALL  COMPRS 
C 

DO  10  N=12,72,12 
M=N-11 

READ(10,1000)  ((DAT(I,JJ),I=M,N),JJ=1,46) 

1000  F0RMAT(F6.  0,11F5.  0) 

10  CONTINUE 

DO  11  J=2,45 

JP1=J+1 

JM1=J-1 

DO  11  1=1,72 

IP1=M0D(I,72) 

IM1=M0D(  1+70, 72)4-1 
S=0.  90 

RHITEC I , J)=( 1.  -S)*DAT( I , J)+(S/4.  )*(DAT( IMl , J)+DAT( IPl , J)  + 
*DAT( I , JP 1 ) +DAT( I , JMl ) ) 

11  CONTINUE 

DO  12  1=1,72 
RHITEC I, 1)=DAT( 1,1) 

12  RHITE(I,46)=DAT(I,46) 

C 

CALL  BLOWUP  (2.2) 

CALL  BASALF  ('STAND') 

CALL  MIXALF  ('L/CSTD') 

C 

CALL  PROJCT  CAITOF') 

C  FOR  AITOFF  PROJECTION 

CALL  PAGE  (10.0,8.0) 

C  SET  PAGE  FOR  VIEWGRAF 

CALL  AREA2D  (8. 5,4.0) 

C 

CALL  XNAME  ('  ' ,1) 

CALL  YNAME  ( '  ' ,1) 

CALL  SCMPLX 

48  CALL  HEADIN  ('THE  WORLD$ ' , 100, 1.  5 , 1) 

C 

99  CALL  YAXANG  (0.  ) 

C 

CALL  MAPGR  (-300. ,30. ,60. ,-90. ,30. ,90. ) 

CALL  GRID  (1,1) 

CALL  MAPFIL  ('HERSHEY') 

CALL  FRAME 
CALL  HEIGHTCO.  05) 

CALL  COMPLX 
CALL  BCOMON(5000) 


WLDOOOlO 

WLD00020 

WLD00030 

WLD00040 

WLD00050 

WLD00060 

WLD00070 

WLD00080 

WLD00090 

WLDOOlOO 

WLDOOllC 

v;ldooi20 

WLD00130 

WLD00140 

WLD00150 

WLD00160 

WLD00170 

WLD00180 

WLD00190 

WLD00200 

WLD00210 

WLD00220 

WLD00230 

WLD00240 

WLD00250 

WLD00260 

WLD00270 

WLD00280 

WLD00290 

WLD003G0 

WLD00310 

WLD00320 

WLD003-)0 

WLD00340 

WLD00350 

WLD00360 

WLD00370 

WLD00380 

WLD00390 

WLD00400 

WLD00410 

WLD00420 

WLD00430 

WLD00440 

WLD00450 

WLD00460 

WLD0047!' 

WLD0048:' 


■VVA-.' 
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Fortran  program  WLDPLT  continued. 

CALL  CONMAKC  RHITE , 7  2 , 46 , ' SCALE ' ) 

CALL  CONMAKC  RHITE ,72,46,' SCALE ' ) 

C  PLOT  SMOOTHED  CONTOURS 

CALL  CONLIN  ( 0, ' SOLID' , 'LABELS’ , 1,5) 

CALL  C0NANG(90.  ) 

CALL  RASPLNCO.  25) 

CALL  CONTURC 1 , ' LABELS ' , ' DRAW ' ) 

CALL  COMPLX 
CALL  HEIGHT(.2) 

CALL  MESSAGC 'DISSPLA  MAP$ ’ , 100 , 3.  5 , -1.  ) 

CALL  RZSETC 'COMPLX' ) 

CALL  RE SETC 'HEIGHT' ) 

CALL  ENDPL(O) 

CALL  DONEPL 

STOP 

END 


WLD00820 

WLD00490 

WLD00500 

WLD00510 

WLD00520 

WLD00530 

WLD00540 

WLD00550 

WLD00566 

WLD00570 

WLB00530 

WLD00590 

VLD00600 

VLDOOeiO 

WLD00620 

WLD00630 


non  on  non  noon  noon  noon  oonnonon 


VJ W Vw.-wvtWW yt'ii'-Tr m'  ’V', ' .r, ■'A rA V  '’A "W v  rj i^”j>Ta^ra^7w 


THIS  IS  A  MAP  GENERATED  TO  COMPARE  RESOLUTION  BETWEEN  DISSPLA 
GENERATED  MAPS  AND  OTHER  DIGITIZED  MAPPING  PROGRAMS. 

THIS  IS  A  MAP  OF  THE  KENNEDY  SPACE  CENTER/CAPE  CANAVERAL  AREA 

LEVEL  0 

CALL  GRAPHICS  DEVICE 
CALL  COMPRS 
LEVEL  1 

SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 

CALL  PAGEC 11.  ,8.  5) 

CALL  SCMPLX 

CALL  PROJCTC 'MERCA' ) 

CALL  MAPMDEC ' STRAI ' ) 

CALL  AREA2D(8.  ,6.  ) 

CALLXNAMEC  ',!) 

CALLYNAMEC  ',!) 

CALL  XAXANG(0.  ) 

CALL  HEADINCCAPE  CANAVERAL  FLA' ,  18 , 1.  5 , 1) 

LEVEL  2 

DEFINE  MAP  PARAMETERS 
CALL  MAPGR(-81.  ,0.  5,-80, ,28.  ,0.  5,29. ) 

LEVEL  3 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 

CALL  MAPFIL('PNOR') 

CALL  MAPFIL('NORT') 

CALL  MAPFIL('USAH') 

CALL  FRAME 
CALL  DASH 
CALL  GRID(1,1) 

CALL  MARKER(-l) 

RETURN  TO  LEVEL  2 

CALL  ENDPL(O) 

RETURN  TO  LEVEL  1 
CALL  DONEPL 

RETURN  TO  LEVEL  0 

STOP 

END 


EZMOOOlO 

EZM00020 

EZM00030 

EZM00040 

EZM00050 

EZM00060 

EZM00070 

EZM00080 

EZM00090 

EZMOOlOO 

EZMOOllO 

EZM00120 

EZM00130 

EZM00140 

EZM00150 

EZ.M00160 

EZM00170 

EZM00180 

EZMQ0190 

EZM00200 

EZM00210 

EZM00220 

EZM00230 

EZM00240 

EZM00250 

EZM00260 

EZM00270 

EZM00280 

EZM00290 

EZM00300 

E2M00310 

EZM00320 

EZM00330 

EZM003/:0 

EZM003.>0 

EZM00360 

EZM00370 

EZM00380 

EZM00390 

EZM00400 

EZM00410 

EZM00420 

EZM00430 

EZM00440 

EZM00450 

EZM00460 

EZM00470 

EZM0048U 

EZM00490 

EZM00'.^> 
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oon  noon  noon  noon  oooooooo 


THIS  IS  A  MAP  OF  THE  OPERATING  AREAS  AROUND  JAPAN 

THIS  PROGRAM  WILL  GENERATE  A  THEATER  LEVEL  MAP  OF  THE  SEA  OF 
JAPAN. 

LEVEL  0 

CALL  GRAPHICS  DEVICE 
CALL  COMPRS 

LEVEL  1 

SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 

CALL  PAGE(8.  5,11.  ) 

CALL  SCMPLX 

CALL  PROJCT('MERCA') 

CALL  MAPMDEC 'STRAI' ) 

CALL  AREA2D(6.  ,8.  ) 

CALLXNAMEC  ’,1) 

CALLYNAMEC  ',!) 

CALL  XAXANG(0.  ) 

CALL  HEADINC ' JAPAN  AND  THE  KURILE  ISLANDS 28 , 1.  5 , 1) 

LEVEL  2 

DEFINE  MAP  PARAMETERS 
CALL  MAPGR(12S.  ,5. ,160.  ,30.  ,5.  ,55.  ) 

LEVEL  3 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 

CALL  MAPFIL(’ASIA’) 

CALL  MAPFILC ’ PASI ' ) 

CALL  FRAME 
CALL  DASH 
CALL  GRID(1,1) 

CALL  MARKER(-l) 

RETURN  TO  LEVELS  2,  1,  AND  0 

CALL  ENDPL(O) 

CALL  DONEPL 

STOP 

END 


JAPOOOlO 

JAP00020 

JAP00030 

JAP00040 

JAP00050 

JAP00060 

JAP00070 

JAP00080 

JAP00090 

JAPOOlOO 

JAPOOllO 

JAP00120 

JAP00130 

JAP00140 

JAP0Q150 

JAP00160 

JAP00170 

JAP00180 

JAP00190 

JAP00200 

JAP00210 

JAP00220 

JAP00230 

JAP00240 

JAP00250 

JAP00260 

JAP00270 

JAP00280 

JAP00290 

JAP00300 

JAP0031Q 

JAP00320 

JAP00330 

JAP00340 

JAP00350 

JAP00360 

JAP00370 

JAP00380 

JAP00390 

JAP00400 

JAP00410 

JAP00420 

JAP00430 

JAP00440 
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THIS  PROGRAM  WILL  GENERATE  A  THEATER  LEVEL  MAP  OF 
MEDITERRANEAN  SEA. 

LEVEL  0 

CALL  GRAPHICS  DEVICE 
CALL  COMPRS 

LEVEL  1 

SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 

CALL  PAGECIS.  ,11.  ) 

CALL  SCMPL.T 

CALL  PROJCTC 'MERCA' ) 

CALL  MAPMDEC 'STRAI' ) 

CALL  AREA2D(13.  .9.  ) 

CALLXNAMEC  ',!) 

CALL  YNAME( '  ' , 1) 

CALL  XAXANGCO.  ) 

CALL  HEADINC MEDITERRANEAN  SEA’ . 17 , 1.  5 , 1) 

LEVEL  2 

DEFINE  MAP  PARAMETERS 
CALL  MAPGR(-10.  ,5.  ,40.  ,25.  ,5.  ,50.  ) 

LEVEL  3 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 

CALL  MAPFIL('PEUR') 

CALL  MAPFIL('EURO') 

CALL  MAPFIL('ASIA') 

CALL  MAPFIL('PASI') 

CALL  MAPFIL('PAFR') 

CALL  MAPFIL('AFRI') 

CALL  FRAME 
CALL  DASH 
CALL  GRID(1,1) 

CALL  MARKER(-l) 

RETURN  TO  LEVELS  2,  1,  AND  0 

CALL  ENDPL(O) 

CALL  DONEPL 

STOP 

END 


MED00030 

MED00040 

MED00070 

MED00080 

MED00090 

MEDOOlOO 

MEDOOllO 

MED00120 

MED00130 

MED00140 

MED00150 

MED00160 

MED00170 

MED00180 

MED00i90 

MED00200 

MED00210 

MED00220 

MED00230 

MED00240 

MED00250 

MED00260 

MED00270 

MED00280 

MED00290 

MED00300 

MED00310 

MED00320 

MED00330 

MED00340 

MED00350 

MED00360 

MED00370 

MEDOOS^-- 

MED00390 

MED00400 

MED00410 

MED00420 

MED00430 

MED00440 

MED00450 

MED00460 

MED00470 

MED0048G 

MED00490 

MED005CC 
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C  THIS  PROGRAM  WILL  GENERATE  A  THEATER  LEVEL  MAP  OF  NORTH-WEST  EUROPE 
C 

C  LEVEL  0 

C  CALL  GRAPHICS  DEVICE 

C 

CALL  COMPRS 
C 

C  LEVEL  1 

C  SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 

C 

CALL  PAGE(8.  5,11.  ) 

CALL  SCMPLX 

CALL  PROJCTC 'MERCA' ) 

CALL  MAPMDEC ' STRAI ' ) 

CALL  AREA2D(6.  ,8.  ) 

CALLXNAMEC  ',!) 

CALLYNAMEC  ’,1) 

CALL  XAXANGCO.  ) 

CALL  HEADINC ' NORTH-WESTERN  EUROPE' ,20 , 1.  5 , 1) 

C 

C  LEVEL  2 

C  DEFINE  MAP  PARAMETERS 

C 

CALL  MAPGR(-10.  ,5. ,15. ,45. ,5. ,62. ) 

C 

G  LEVEL  3 

C  CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 

C 

CALL  MAPFIL(’PEUR') 

CALL  MAPFILCEURO' ) 

CALL  FRAME 
CALL  DASH 
CALL  GRID(1,1) 

CALL  MARKER(-l) 

C 

C  RETURN  TO  LEVELS  2,  1,  AND  0 

C 

CALL  ENDPL(O) 

CALL  DONEPL 

STOP 

END 


UTQiOOOlO 

UKM00020 

UKM00030 

UKM00040 

UJT/.OOOSO 

UKM00060 

UKM00070 

UKM00080 

UKM00090 

UKMOOlOO 

UKMOOllO 

UKM00130 

UXM00140 

UKM00150 

UKM00160 

UKM00170 

UKMOOISO 

UKM00190 

UKM00200 

UKM00210 

UKM00220 

UKM00230 

UKM00240 

UKM00250 

UKM00260 

UKM00270 

UKM00280 

UKM00290 

UKM00300 

UKM003ia 

UKM00320 

UKM00330 

UKM00340 

UKM00350- 

UKM00360 

UKM00370 

UKM00380 

UKM00390 

UKM00400 

UKiM00410 

UKM00420 


APPENDIX  C.  KERMIT  ON-LINE  HELP  FILES 


This  is  a  printout  of  a  help  file  which  is  resident  on  the  Columbia  University  Computer. 
It  is  updated  about  once  a  year.  This  version  is  accurate  to  28  Jan  88. 


COLUMBIA  UNIVERSITY  KERMIT  DISTRIBUTION 

This  file  explains  what  files  are  in  the  Kermit  distribution  and  gives  the  naming 
conventions  for  them. 

If  you  are  reading  this  from  a  handout  supplied  with  a  Kermit  distribution  tape, 
please  note  that  this  information  might  not  be  quite  up  to  date  -  there  may  be  files  on 
the  tape  that  are  not  listed  here.  The  copy  of  this  file,  AAFILES.HLP,  on  the  tape 
might  be  more  current. 

The  file  AAFILx.DIR  contains  an  up-to-date  alphabetical  directory  listing  of 
all  the  files  in  the  respective  Kermit  distribution  area  (KER:,  Tape  A;  K2;,  Tape  B; 
K3:,  Tape  C;  etc.)  -  one  such  file  is  created  in  each  area  by  a  nightly  batch  job  (x  is 
A,  B,  C,  etc).  The  directory  listing  supplied  on  paper  with  your  tape  should  reflect 
exactly  which  files  are  on  the  tape,  and  in  what  order. 

The  Kermit  distribution  areas  include  all  the  versions  of  Kermit  which  are  in  our 
possession.  The  files  have  names  of  the  form 

NAME.TYPE 

where  NAME  is  the  name  of  file,  and  TYPE  is  its  type 
(program  source,  documentation,  executable  core  image, 
etc).  No  NAME  is  more  than  9  characters  long  (the 
maximum  accepted  by  VAX,' VMS),  and  every  NA.ME  starts  with 
a  letter  and  is  unique  in  the  first  6  characters  (the 
maximum  under  TOPS- 10,  RSTS.  E,  etc).  On  TOPS-10  BACKUP 


Interchange  tapes,  names  longer  than  6  will  be  truncated 
to  6.  No  type  is  longer  than  3  characters.  NAME  and 
TYPE  are  separated  by  a  period. 


*  Types 

The  files  types  don't  follow  a  strict  convention  because  the  .fles  originate  on  so  many 
different  systems.  But  there  are  some  patterns;  here  are  some  commonly  used  file  types 

For  Tgxt  Filss: 

. BID  -  Instructions  for  building 

.  BWR  -  A  "beware"  file,  listing  known  bugs,  limitations, 
or  other  problems 

.DIF  -  Differences  (produced  by  file  comparison 
program) 

.DOC  -  Documentation  (usually  long) 

.  HLP  -  Help  message  (like  DOC  but  usually  shorter) 

.  INS  -  Installation  instructions 
.  MAN  *  A  manual 

.MEM  -  Documentation  ("memo")  produced  by  DEC  Runoff 
.MSG  -  A  text  or  mail  message  of  some  kind 
.MSS  -  Scribe  text  formatter  source  (for  some  of  the 
.DOC  files) 

.NR  -  Nroff  text  formatter  source 
. RNH  -  Runoff  text  formatter  source  for  .HLP  files 
.  RNO  -  Runoff  text  formatter  source  for  .MEM  files 
.  TEX  ”  TeX  source 

.TXT  -  Text  (usually  shorter,  sometimes  in  electronic 
mail  message  format) 

.  UPD  -  Program  update  history 


.  A  -  Assembler 
.A68  -  Algol-68 
.  A86  -  8086  assembler 
.AOA  -  Ada 
.ALG  -  Algol-60 
. ASM  -  Assembler 
. B  -  B  language 
. BAS  -  Basic 
.  BLI  -  Bliss 

.BOO  -  "boo"  format  printable  encoding  of  object  or  executable  program 
. C  -  C  language 
.  CLU  -  CLU  language 
.F  -  Fortran  (Unix) 

.F77  -  Fortran-77 
. FOR  -  Fortran 
. FTN  -  Fortran 

.H  -  header  file  for  C  or  ASM  program 

. H86  -  8086  hexadecimal  encoding  of  object  or  executable  program 
.HEX  -  Hexadecimal  encoding  of  object  or  executable  program 
. HQX  -  "binhex"  encoding  of  object  or  executable  program 
. LSP  -  Lisp  source  code 
.MAC  -  Macro  assembler 
.  MAR  -  VAX  assembler 
. PAS  -  Pascal 


I 
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PL/C 
PL/ 1 
PL/M 

VAX  "require"  (header)  file 


A  FORTH  "screen" 


-  Source  program 


BAT  -  A  batch  control  file  (e.  g.  for  MS-DOS) 

CMD  -  A  command  file  of  some  kind 

COM  -  VAX  or  PDP-11  DCL  command  file 

CTL  -  A  batch  control  file  (e.  g.  for  DEC-10/20) 

INI  -  Initialization  command  file 

JCL  -  Job  control  language  (e.  g,  for  Harris) 


*  Prefixed  File  Names: 

The  file  names  for  files  associated  with  each  implementation  of  Kermit  are  prefixed 
by  a  few  characters  denoting  the  implementation.  Although  the  files  are  kept  in 
separate  areas,  each  prefix  is  unique  among  all  the  Kermit  files,  so  that  areas  can  be 
combined  into  a  single  area  without  any  confusion.  The  following  are  presently  used, 
(Items  marked  with  asterisk  have  fuller  explanations  below): 


--'•micros*'  (tape  Al  -- 

Prefix  Machine(s) 

Operating  System 

Language 

APP 

Apple  II 

DOS  3. 3  or  ProDos 

6502  Asm 

AST 

Atari  ST  Series 

GEM 

C 

ATA 

Atari  Home  Computer 

DOS 

Action! 

C64 

Commodore  64 

DOS 

CROSS 

*C86 

8086/8088  (see  below) 

CP/M-86 

ASM86 

CC 

TRS-80  Color  Computer 

Disk-Extended  Color 

BASIC  EDTASM 

*CP4 

8080, 8085, Z80(see  below)  CP/M-80 

LASM 

*CPM 

8080,8085,280  --  obsolete,  see  below  -- 

CX 

Experimental  new  release  of  CP/M-80  Kermit 

LASM 

K6 

0S9/68000  Portable 

various 

Assembler 

M4 

TRS-80  Model  4 

TRSDOS 

ASM 

*MS 

Various  (see  below) 

MS-DOS  or  PC -DOS 

MASM 

QK 

(various,  see  below) 

Turbo  Pascal 

TA2 

Tandy  2000 

MS  DOS 

MASM 

TRS 

TRS-80  I  and  III 

TRSDOS 

280  Ass. 

TR2 

TRS-80  Model  II 

TRSDOS 

280  Ass. 

WIN 

IBM  PC,  etc 

MS-DOS  w/MS-Windows 

Microsoft  C4.  0 

WK 

IBM  PC  family 

PC  DOS 

Lattice  C 

*  See  below  for  notes  about  MS-DOS  and  CP,' .VI  Kernnits. 
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, 


Prefix  Machine(s) 


Operating  System  Language 


*CK 

VAX,  SUN,  many  others 

UNIX 

C 

*CK 

VAX 

VMS 

C 

*CK 

Apple  Macintosh 

Mac  OS 

C 

*CK 

Commodore  Amiga 

AmigaDOS/ Intuition 

c 

*CK 

Data  General  MV  Series 

AOS/VS 

c 

*CK 

Apollo 

Aegis 

c 

CM2 

IBM  370  Series 

VM/CMS 

Pascal/VS 

IK 

IBM  370  Series 

VM/CMS 

IBM  Ass. 

KIO 

DECsystem-10 

TOPS- 10 

MACRO- 10 

*K11 

DEC  PDP-11 

RSXl 1 , RSTS /E , RTl 1 , TSX 

MACRO- 11 

*K11 

DEC  PDP-11 

P/OS,  Pro/RT,  IAS  3.1 

MACRO- 11 

K20 

DECSYSTEM-20 

TOPS -20 

MACRO -20 

MP 

DEC  PDP-11 

MUMPS  (M/ll) 

MUMPS 

*TS0 

IBM  370-series/370S 

MVS/TSO 

Assembler 

*TS2 

IBM  370-series/Seriesl 

MVS/TSO 

Pascal/ VS, PL/ I, etc. 

*TS3 

IBM  370-series/3708 

MVS/TSO 

Assembler 

*TSN 

IBM  370-series/3705 

MVS/TSO 

Ass. /ALP 

ux 

Old,  old,  small  Unix  Kermit 

C 

*VMS 

VAX 

VMS 

Bliss-32 

*  C-Kermit  (Prefix  CK,  Tape  B): 

C-Kermit  is  a  transportable  version  of  Kermit  written  in  the  C  language.  It  is 
composed  of  many  modules,  some  system-  independent,  some  system-specific.  C- 
Kermit  has  been  implemented  on  many  systems,  some  "mainframes"  and  some 
"micros".  In  particular,  the  Unix  version  runs  on  machines  ranging  from  large  IBM 
mainframes  to  VAX  and  other  minicomputers  to  small  PC's,  and  Kermit  programs  for 
the  Apple  Macintosh,  the  Commodore  Amiga,  VAX, VMS,  DG  AOS;VS,  Apollo 
Aegis,  CDC  VX/VE,  and  many  other  systems  can  also  be  generated  from  C-Kermit. 
All  the  C-Kermit  source  files  are  kept  together  on  tape  B  to  avoid  the  problems  that 


would  be  introduced  by  splitting  up  the  files  or  keeping  duplicate  copies.  See  the  file 
CKAAAA.HLP  for  an  explanation  of  the  file  naming  conventions  for  C-Kermit. 

*  The  Kll  files  include  support  for  RSX,  RSTS,  RTll,  TSX  +  ,  IAS, 

and  P/OS  --  See  K11INS.DOC  for  details. 

*  The  VAX/VMS  Bliss  version  is  also  provided  in  MACRO-32  (.MAR) 

source  form  for  those  sites  that  do  not  have  a  Bliss 

compiler,  as  well  as  in  a  hexadecimal  encoding  of  the  task 

image.  YOU  DON'T  NEED  TO  HAVE  BLISS  IN  ORDER  TO  RUN  THIS 

VERSION.  See  VMSAA.\.HLP. 

*  Among  the  TSO  Kermits,  you  should  probably  try  the  TSN  version 

first.  The  TSO  versions  (one  for  linemode,  a  separate  one 
for  Series/ 1 -style  3270  emulation)  are  very  old  and 
primitive.  The  Pascal  version  requires  a  Pascal  compiler 
and  supports  only  linemode  connections.  The  TSN  version, 
from  NTH,  supports  only  linemode  connections,  but  includes 
many  advanced  features.  There's  also  version  with  the 
prefix  TS3,  which  supports  the  3708  front  end.  Many  of 
these  will  be  replaced  by  "portable  370"  Kermit  soon,  under 
prefix  IKO  and  IKT. 

For  VM/CMS,  please  try  the  new  IK*.*  version.  This  is  "portable  370"  Kermit, 
which  is  a  very  advanced  Kermit  implementation,  to  which  support  for  other  IB.M  370 
operating  systems,  like  MVS/TSO,  DOS/VSE,  MTS.  MUSIC,  etc,  should  be  easy  to  add. 
It  suppons  most  of  the  advanced  Kermit  options  (long  packets,  etc),  and  both  line  mode 
and  full  screen  connections. 


tape  C 


1 

1 


Prefix  Machine(s) 

Operating  System 

Language 

AC 

Acorn  BBC  Workstation 

Panos 

C 

AM 

Alpha  Micro  68000 

AMOSL 

Alpha  Asm 

68K 

APL 

Apollo 

Aegis 

Pascal 

APO 

Apollo 

Aegis 

Pascal 

BBC 

Acorn  BBC  Micro 

OS 1,2, 3, Panos 

(various) 

CIE 

CIES  680/XX 

REGULUS 

C 

CN8 

(various) 

Concurrent  CP/M-86 

ASM86 

EXP 

TI  Explorer 

Common  Lisp 

FL 

Motorola  6809 

FLEX-09  or  SK*D0S 

C  or  6809 

Asm 

HL6 

Honeywell  L6/10 

MS-DOS 

MASM 

HP2 

HP-264X 

7 

8080  Asm 

HP8 

HP-86,  HP-87 

HP  BASIC 

HP  BASIC 

HP9 

HUCSD  p-System 

HP  Pascal 

186 

Intel  86/380 

iRMX-86 

PL/M 

IRMX 

Intel  86/380 

iRMX-86 

PL/M 

LM 

LMI  or  Symbolics 

Lisp  Machines 

ZetaLisp 

LUX 

Luxor  ABC -800 

ABCDOS 

BASIC-II 

M2 

Lilith  Workstation 

Medos 

Modula-2 

MD2 

Intel  Development  System  ISIS 

PL/M 

MDS 

Intel  Development  System  ISIS 

PL/M 

0S9 

Various 

0s9 

C 

PQK 

ICL/3  Rivers  PERQ 

PERQ  OS 

Pascal 

PRO 

DEC  Professional-350 

P/OS 

Bliss 

QLK 

Sinclair  QL 

QDOS 

C 

QL2 

Sinclair  QL 

QDOS 

BCPL 

m 


w  V  V*j*  V  W ' 


V  *•"  *.•  V  V  V  "•*  V  *.*•  V  •j' "-" 

--  *-  o  •-  <r  v*  o  o  o  •*.-*  o  N--  ^.•  <• 


Prefix  Machine(s) 


Operating  System  Language 


QNX 

IBM  PC,  Rainbow,  etc 

QNX 

C 

RML 

Research  Machines 

ROS,  ... 

C 

RMX 

Intel  286/10,  etc 

RMX-86 

PL/M 

TRI 

various 

TRIPOS 

BCPL 

UCA 

Apple  II 

UCSD  p-System 

Pascal 

UCI 

IBM  PC 

UCSD  p-System 

IV.  X 

Pascal 

UCJ 

Joyce  Loebl  Magiscan 

2  UCSD  p-System 

Pascal 

UCM 

Pascal  Microengine 

UCSD  p-System 

Pascal 

UCT 

Terak  8510a 

UCSD  p-System 

II.  0 

Pascal , Macro-11 

UM 

U-Micro  U-Man  1000 

CP/M-68K 

C  &  68000 

VIC 

Sirius  1/Victor  9000 

MS-DOS 

C 

Prefix  Machine(s) 


Operating  System  Language 


AOS 

Data  General 

AOS,  AOS/VS 

Fortan, Pascal 

B68 

Burroughs  B6800 

7 

Algol 

B78 

Burroughs  B7800  &  A 

7 

Algol 

B79 

Burroughs  B7900 

7 

Algol 

GDC 

GDC  Gyber  170 

NOS 

Fortran-77 

CD3 

GDG  Gyber 

NOS 

Fortran  5 

CR 

Gray-1,  Gray-XMP 

GTSS 

Fortran-77 

*CUC 

(various) 

Unix 

C 

CVK 

Gomputervis ion 

CGOS 

Fortran  S 

CYB 

GDC  Cyber 

NOS  2.2 

Compass 

DGM 

Data  General 

AOS/VS  with  MV/UX 

C 

DTS 

Honeywell  6000 

DTSS 

Virtual  PL/ I 

GEC 

GEC  4000  Series 

OS-4000  (RAL) 

SERC 

GM 

Gould/SEL-32 

MPX-32 

Fortran  77+ 

GUTS 

IBM  370  Series 

GUTS 

Assembler 

HI 

Harris  100 

VOS 

Fortran 

H8 

Harris  800 

VOS 

Pascal,  Asm 

HC6 

Honeywell  DPS  8,  66 

CP6 

PL/6 

HCP 

Honeywell  DPS  8,  66 

CP6 

Pascal 

HD6 

Honeywell  DPS  6 

GCOS  6 

?(no  source) 

HDP 

Honeywell  DPS  8,  66 

GCOS 

B 

HG 

Honeywell  DPS  8,  66 

GCOS3  or  8 

C 

HP3 

Hewlett-Packard  3000 

MPE 

SPL 

HPM 

Hewlett-Packard  1000 

RTE-6/VM  &  RTE-A 

F-77  &  Asm 

t*m  AV*  At&'A*a  Ata*’afA' 
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--  uess  popular  minis  at  main 

Prefix  Machine(s) 

.trames  i  rape  u  i  i  coi 

Operating  System 

q)  -- 

Language 

IBM 

370  Series 

MUSIC 

Assembler 

K08 

DEC  PDP-8 

0S8,  RTSS 

PAL-8 

DEC 

PDP-8 

OS-278 

PAL- 8 

MOD 

MODCOMP  Classic 

MAX  IV 

Fortran/ASM 

MTS 

IBM  370  Series 

MTS 

Asm,  Pascal 

IfTZ 

IBM  370  Series 

MTS 

PLUS 

MU 

Honewyell 

MULTICS 

PL/ 1 

ND 

ND-10/100/500 

Simtran  III  Rev  J 

ND  Pascal  J 

CDC  Cyber 

NOS  2.4 

Compass 

PER 

Perkin-Elmer  3200 

OS/32 

Fortran 

Perkin-Elmer  3200 

OS/32  MT72 

Fortran 

PE  7 

Perkin-Elmer  7000 

IDRIS 

C 

PIC 

Microdata  (McD-Dougl) 

REALITY  (PICK) 

DATA/ BASIC 

PRI 

PRIME 

PRIMOS 

PL/P  (PL/ I) 

RDOS 

Data  General  Nova 

RDOS 

Fortran 

RD2 

Data  General  Nova 

RDOS 

Basic 

RT 

PDP-11 

RT-11 

OMSI  Pascal 

SP9 

Sperry  90/60 

VS9 

Assembler 

ST 

HP3000,  Univac,  etc 

Software  Tools 

Ratfor 

TAN 

Tandem 

Nonstop 

TAL 

TI9 

TI-990 

DXIO 

Pascal 

UN 

Sperry/Univac-1100 

EXEC 

Assembler 

VME 

ICL  2900 

VME 

S3 

VX 

VAX 

VMS 

Pascal  and  Fortran 

*  UCL  C-Kermit  (Prefa  CUC,  Tape  D); 

A  trim  version  of  Kermit  from  England,  written  in  C,  without  all  the  fancy  features 
of  the  above  C-Kermit,  but  possibly  somewhat  more  efficient.  Runs  on  Berkeley  and 
ATT  Unix  svstems. 


BY 

Byte  Mag  Kermit  Article,  Jun-Jul  84 

English 

GER 

Kermit  documentation  in. , . 

German 

IBM 

IBM  mainframe  Kermit  discussion  panel 

English 

KP 

Kermit  Protocol  Manual 

English 

KU 

Kermit  User  Guide 

English 

MA 

Info-Kermit  Electronic  Mail  Digests  '83-now 

English 

NEW 

Kermit  Newsletters 

English 

FOR 

Kermit  documentation  in. . . 

Portuguese 

*  Manuals  and  other  documentation  (Tape  E): 

Note:  The  protocol  manual  and  user  guide  were 
recently  moved  to  Tape  E  due  to  lack  of  space  on  the 
other  tapes. 

There  are  two  Kermit  manuals:  KUSER  and  KPROTO,  a  user's  guide  and  a 
protocol  manual,  respectively.  They  are  provided  in  three  forms: 

.MSS  Scribe  (UNILOGIC  Ltd  text  formatter)  source. 

.DOC  No  special  effects,  suitable  for  reading  at  a  terminal. 

.FOR  Fortran  carriage  control  for  overprinting,  etc. 

If  you  have  Scribe  and  the  appropriate  Scribe  device  drivers,  you  can  run  the 
.MSS  files  through  it  to  produce  output  suitable  for  printing  on  any  device  supported 
at  your  site,  including  the  Xerox-9700,  Imagen,  Apple  LaserWriter,  or  other 
multifont  laser  printers  or  photocomposers.  Note  that  some  parts  of  the  user  manual 
rely  on  underlining  to  clarify  examples;  the  underlines  are  missing  from  the  .DOC  files, 
but  will  be  produced  if  you  run  the  .MSS  files  through  Scribe  for  a  device  capable  of 
underlining  (line  printer,  daisy  wheel,  laser  printer,  etc). 

The  user's  guide  is  intended  for  users  of  Kermit  (including  those  who  want  to  install 
it),  the  protocol  manual  is  for  those  who  would  like  to  ^vrite  a  new  implementation 
(i.e.  a  Kermit  program  for  a  new  machine  or  operating  system). 
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IMPORTANT:  The  Users  Guide  is  always  out  of  date.  New  implementations 
of  Kermit,  and  new  versions  of  old  ones,  arrive  in  a  steady  stream.  It's  impossible  to 
keep  the  manual  totally  current.  The  general  description  of  Kermit  operation  remains 
valid,  but  detailed  descriptions  of  the  various  versions  are  better  obtained  from  the 
accompanying  help  (.HUP),  beware  (.BWR),  documentation  (.DOC),  memo  (.MEM), 
or  manual  (..MAN)  files.  Look  to  these  files  for  information  missing  from  the  user 
manual. 

For  a  detailed  presentation  of  Kermit,  from  tutorials  on  computers,  files,  and 
data  communications,  to  a  thorough  description  of  the  protocol  itself,  plus  a  com¬ 
mand  reference,  command  summary,  troubleshooting  guide,  glossary,  index,  and  many 
tables  and  illustrations,  see  the  book  "Kermit,  A  File  Transfer  Protocol,"  by  Frank  da 
Cruz,  Digital  Press  (1986),  ISBN  0-932376-  88-6,  available  from  Kermit  Distribution  at 
Columbia,  or  directly  from  Digital  Press,  12A  Esquire  Road,  Billerica,  MA  01862,  order 
number  EY-6705E-DP,  S25.00. 

.^SCII.MSS  is  the  ASCII/EBCDIC  character  table,  which  is  included  as  an  ap¬ 
pendix  in  both  manuals. 

KUSER.HYP  is  a  hyphenation  dictionary  for  building  the 
manuals  with  Scribe. 

BYTE.MSS  is  the  manuscript  of  the  KERMIT  article  that 
was  published  in  BYTE  .Magazine  in  June  and  July, 

1984. 

BYTE.DOC  is  suitable  for  reading  at  the  terminal, 

BYTE.MSS  may  be  run  through  Scribe  to  produce 
output  for  various  printing  devices,  BYTE. BIB  is 
the  bibliography. 

MAIL.*  is  the  archive  of  the  CCNET/BITNET/ARPANET  KER.MIT 
discussion  group. 

-MAIL. TXT  is  the  current,  active  mail  file,  found  on  Tape  A. 


MAIL.yyx  (e.g.  MAIL.83A)  files  contain  older  messages, 
and  these  are  kept  on  Tape  C. 

MAIL.HLP  describes  the  format  of  the  mail  files. 

***  IMPORTANT 

Before  doing  anything  with  any  particular  version,  look  for  an  associated  file  with 
the  suffix  ".HLP"  (help)  or  ".BWR"  (beware).  These  files  will  often  tell  you  special 
things  you  should  know  before  starting  to  put  together  a  working  program  from  the 
distribution. 

*  MS-DOS  Kermit  Implementations  (Prefix  MS,  Tape  A): 

See  the  file  MSAAAA.HLP  for  an  explanation  of  .MS-DOS  Kermit  file  naming 
conventions.  The  following  .BOO  files  are  provided  for  current  MS-DOS  imple- 
mentions.  BOO  files  are  dowruoaded  and  decoded  into  .EXE  files  using 
MSBOOT.FOR  on  the  mainframe  and  MSBPCB.BAS  on  the  MS-DOS  system,  or 
downloaded  directly  to  the  PC  and  translated  to  .EXE  files  using  MSBPCT.BAS  or 
MSBPCT.EXE  (compiled  from  MSBPCT.C),  or  MSBPCT.PAS  (Turbo  Pascal).  Some 
of  the  .MSV*.BOO  files  correspond  to  version  2.30  of  .MS-DOS  Kermit,  others  to  2.29, 
and  still  others  perhaps  even  to  earlier  version.  It  depends  on  which  was  the  latest  ver¬ 
sion  successfully  tested  or  that  machine.  For  fallback  purposes,  BOO  files  for  old  re¬ 
leases  for  some  systems  may  be  found  in  MSO*.BOO.  Beta  tests  of  new  releases  are 
in  MST*.BOO. 

MSV55X.BOO  Sanyo  MBC-550  with  IBM  compatible 

video  board 

MSVAP3.BOO  NEC  APC3 

MSVAPC.BOO  NEC  APC 

.MSVAPR.BOO  ACT  Apricot 

MSVDM2.BOO  DECmate-11,111  with  XPU  (.MS-DOS) 


option 


MSVGEN.BOO  Generic  MS-DOS 

MSVGRI.BOO  Grid  Compass  II 

MSVHPl.BOO  Hewlett-Packard  150 

MSVHPX.BOO  HP-1 10  and  HP  Portable  Plus 

MSVIBM.BOO  IBM  PC,  Portable  PC,  XT,  AT,  PCir^^*, 
and  compatibles 

MSVMBC.BOO  Sanyo  MBC-550 

MSVR31.BOO  DEC  Rainbow  100  Series 

MSVRB2.BOO  A  special  fancy  Rainbow  version  that 

does  VT220  emulation 

MSVRMX.BOO  Intel  300  series  with  iRMX-86 

MSVTIP.BOO  Texas  Instruments  Professional  PC 
MSVWNG.BOO  Wang  PC 

MSVZIO.BOO  Heath/Zenith  100 

MXVV90.BOO  Victor  9000  (Sirius  1) 

Source  and  other  MS-DOS  Kermit  files: 

MSSDEF.H,MSS*.ASM  Sources 
MSG*.ASM  System  dependent  graphics  terminal 
emulation 

MSU*.ASM  System  dependent  keyboard  support 

MSX*.ASM  System  dependent  source  modules 

MSY*.ASM  Terminal  emulation  modules 

MSZ*.ASM  Continuation  of  terminal  emulation 

when  MSY  module  too  big 

MSKERM.DOC  Kermit  User  Guide  chapter  for  MS-DOS 
Kermit  (long) 

MSKERM.HLP  Brielf  list  of  MS-Kermit  commands 
MSKERM.BWR  "Beware  File"  —  Known  bugs  & 
limitations.  Read  it! 

.MS*.HLP,  MS*.BWR  Help  and  Beware  files  for  specific 


systems. 
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The  IBM  version  runs  on  the  entire  IBM  PC  and  PS/2  families,  clones  and  compat¬ 
ibles  (e.g.  Compaq,  AT&T  6300,  DEC  VAXmate),  and  near-clones  like  the 
Heath/Zenith  100  with  L’CI  EZPC  board,  Olivetti  M24,  Seequa  Chameleon,  and  Data 
General,'  1. 

The  generic  version  (MSVGEN)  should  run  on  any  MS-DOS  system,  because 
it  operates  using  only  DOS  calls.  But  this  means  it  runs  slowly  (usually  1200  baud  or 
less),  and  cannot  do  fancy  screen  management  or  terminal  emulation. 

The  Tandy,  Honeywell,  and  some  other  MS-DOS  versions  listed  above  under  their 
owm  prefixes  are  based  on  older  versions  of  IBM  PC  Kermit;  these  have  yet  to  be  merged 
w^tb  he  current  .VIS/PC-DOS  version.  Volunteers? 

*  WKERMIT  (Tape  A): 

An  adaptation  of  an  early  version  of  C-Kermit  to  run  on  the  IB.M  PC  family  and 
compatibles.  It  is  the  first  PC  implementation  of  Kermit  with  the  sliding  window  pro¬ 
tocol  extension.  The  .EXE  file  is  formatted  as  a  .BOO  file  (see  above).  It  requires 
a  modem,  or  a  null  modem  cable  that  provides  normal  modem  signals.  The  source  code 
for  WKER.MIT  should  not  be  used  as  the  basis  for  any  development,  as  it  is  several 
releases  behind  C-Kermit. 

*  WINKERM  (Tape  A): 

A  version  of  Kermit  specifically  tailored  for  the  multitasking  Microsoft 
Windows  environment. 

*  CP/.M-80  Kermit  Implementations  (Tape  A): 

The  following  .HEX  files  for  specific  CP/.M-80  implementations  are  in¬ 
cluded: 

CP4*.ASVI  The  current,  working  source  files  for  CP,'M 
KER.MIT. 


CP4KER.DOC  User  documentation  (chapter  from  the 
manual). 

CP4KER.HEX  System-independent  portion,  to  be  combined 
with  one  of  the  following  system-dependent 
"overlays": 

CP4380.HEX  Research  Machines  RM380Z 
CP438M.HEX  Research  Machines  RM3S0Z 
CP4S20.HEX  Xerox  820 
CP4ACC.HEX  Access-Matrix 
CP4ADV.HEX  North  Star  Advantage 
CP4APC.HEX  Apple  II,  Z80  Softcard,  CPS  serial  card 
CP4APL.HEX  Apple  II,  Z80  Softcard,  6551  ACIA  in 
serial  interface 

CP4APM.HEX  Apple  II,  Z80  Softcard,  Micromodem  II  in 
slot  2 

CP4BB2.HEX  BigBoard  II  (terminal  required) 

CP4BBC.HEX  Acorn  BBC  Micro,  Z80  second  processor 
CP4BRA.HEX  Intertec  SuperBrain,  aux  port. 

CP4BRM.HEX  Intertec  SuperBrain,  main  port. 
CP4BRN.HEX  Intertec  SuperBrain. 

CP4CIF.HEX  Cifer  1886 
CP4COM.HEX  Comart  Communicator 
CP4CP3.HEX  "generic";  CP,'M  3.0  (CP/M  Plus)  systems 
(terminal  req'd) 

CP4CPT.HEX  CPT-85XX  word  processors  with  CompuPak 
CP/M 

CP4CRO.HEX  Cromemco 

CP4DEL.HEX  Digicomp  Delphi  100  (terminal  required) 
CP4DIS.HEX  Action  Computer  Enterprises  Discovery 
CP4D.M2.HEX  DECmate  II  with  CP/.M  option 
CP4GEN.HEX  "generic";  CPM  2.2  systems  with  lOBYTE 
(terminal  req'd) 
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CP4H89.HEX  Heath/Zenith  H89. 

CP4H0R,HEX  North  Star  Horizon  without  SIO  board 
CP4HP1.HEX  Hewlett-Packard  125 
CP4KPR.HEX  Kaypro-II  (and  4;  probably  supports  all 
Kaypro  systems) 

CP4LOB.HEX  Lobo  Max-80 

CP4MDI.HEX  Morrow  Decision  I  (terminal  required) 
CP4M1K.HEX  MikroMikko 

CP4NST.HEX  Northstar  Horizon  with  Northstar  CP,'M  and 
SI 0-4  board 

CP40SB.HEX  Osborne  1 
CP40SI.HEX  Ohio  Scientific 

CP4PMM.HEX  Personal  Micro  Computer  MicroMate 
CP4PX8.HEX  Epson  PX8  Portable 
CP4R0B.HEX  DECVT180 
CP4TEL.HEX  TELCON  Zorba  portable 
CP4TLB.HEX  TRS-80  model  II  with  Lifeboat  2.25C  CP/M 
Display 

CP4T0R.HEX  BBC  Torch  Series 

CP4TPT.HEX  TRS-80  model  II  with  Pickles  +  Trout  CP/M 
Display 

CP4TTK.HEX  Teletek  with  ADM.22  terminal 

CP4UDI.HEX  Morrow  Micro  Decision  I  (terminal  required) 

CP4VEC.HEX  Vector  Graphics. 

CP4Z00.HEX  Z- 100  under  CP/M-85 


The  following  arc  standalone  hex  files  that  can  be  directly  loaded  (not  combined 
with  CP4KER.HEX); 

CPMH8.HEX  Heath  H8  (based  on  version  3.5  of  CP/M-80 
Kermit) 

CP.MPRO.HEX  Compupro  Interfacer  3/4  (based  on  version 
3.9) 

CP.MSYO.HEX  Sanyo  MBC  1100  (version  3.9) 


80 


The  Kermit  User  Guide  contains  instructions  for  installing  or  bootstrapping  the 
various  versions  of  CP.'M  Kerniit.  The  bootstrapping  program  is  also  stored  in  the 
files  CP4FET.*.  A  BASIC  program,  CP4HEX.BAS,  can  be  used  on  the  CP  M 
system  to  verify  and  edit  a  downloaded  hex  file  prior  to  loading. 

CP/M-86  Kermit  Implementations  (Tape  A): 

The  CP,'M-86  Kermit  file  names  all  start  with  CS6.  Those  whose  fourth  char¬ 
acter  is  X  are  system-dependent  files  for  particular  systems: 

C86XAP  NEC  APC 

C86XFJ  Fujitsu  Micro  16s 

C86XFU  Future  FX20/FX30 

C86XRB  DEC  Rainbow,  CP;M-86;80  V2  (C86XR2  is  an 

alternate  version) 

C86XTX  Tektronix  4170 

C86XV9  Victor  9000, 'Sirius  1 

The  .H86  files  are  hex  files,  convertible  to  runnable  .CMD  files  by  running  them 
through  GENCMD  on  the  micro.  There's  also  a  Concurrent  CP/M-86  version  under 
the  prefix  CN8  (on  Tape  C). 

*  Queen's  University  Turbo  Pascal  Kermit  (Tape  A) 

Runs  on  several  systems.  All  source  files  concatenated  together  into  a  big  source 
file,  QKKER.PAS,  with  component  file  separated  by  lines  like 

(*  +FILE+  filename  *) 

The  runnable  program  image  (.COM  file)  is  encoded  into  straight  hexadecimal 
(2  hex  digits  for  one  byte  from  the  .COM  file)  for  the  following  systems: 


QKMSTV.HEX 


IBM  PC  family,  .MS-DOS,  with  VTIOO  & 


,  -  r-  r  . 


Tektronix  4010  emulation 

QKMSVT.HEX  IBM  PC  family,  MS-DOS,  with  VTIOO 
emulation 

QKCPK2.HEX  Kaypro  II,  CP,'M-80 

QKAPP2.HEX  Apple  II,  DOS 

A  simple  Turbo  Pascal  program  is  provided  to  convert  these  hex  files  back  into 
■  COM  files  —  QKHEXC.PAS.  Key  definition  files  are  also  provided;  you  need  to 
have  one  on  your  current  disk  in  order  to  run  the  program. 

*  Other  Files  (All  tapes): 

AAAREAD.ME  is  a  file  that  describes  some  other  files 
w'hich  can  help  you  find  your  w’ay  among  the 
hundreds  of  Kermit  files. 

AAFILES.HLP  is  this  file. 

AATAPE.HLP  explains  the  format  and  layout  of  Kermit 
tapes. 

AAXFLY.DOC  is  the  Kermit  "brochure"  and  order  form. 

AAVNEW.HLP  is  a  list  of  the  current  versions  of  Kermit 
in  reverse  chronological  order,  to  help  you  see 
what  has  changed  since  the  last  lime  you  looked. 

AtAWAIT-HEP  is  a  list  of  Kermit  versions  reportedly  under 
development,  for  which  we  are  still  waiting. 

AAXCOM.HLP  is  a  policy  statement  concerning  commercial 
use  of  Kermit. 

AABLIND.HLP  is  a  list  of  hints  for  use  of  Kermit,  and 
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microcomputers  in  general,  by  the  blind  or  people 
with  other  disabilities. 

KERMIT.FOR  is  a  short  receive-only  version  of  Kermit 
written  in  Fortran,  to  be  used  for  bootstrapping 
Kermit  onto  systems  that  don't  have  a  real  Kermit 
from  a  system  that  does. 

''  Tools  (Tape  A): 

LASM  and  MLOAD  are  the  public-domain  CP  M-80  linking  assembler  and 
loader,  that  run  on  the  CP/M  system,  and  may  be  used  to  buUd  Kermit-80. 

UUDECO.C  is  a  version  of  UUDECODE  that  has  been  changed  to  supply  any 
trailing  blanks  on  lines  in  UUENCODEd  files  that  may  have  had  them  stripped  off 
by  electronic  mail  (like  on  BITNET). 

XXU.C  is  a  program  for  use  on  Unix  systems  that  renames  files  with  "foreign" 
names  (e.g.  uppercase,  or  including  directory  or  path  information,  generation 
numbers,  etc),  to  have  normal  Unix-style  names. 

XXTAPE.*  is  a  program  to  write  ANSI  and  EBCDIC  labeled  tapes  on  a  Unix 
system.  Also  needs  XXATOE.C. 

APXA*.*  is  a  program  written  in  C  that  does  what  CROSS  does,  but  only 
produces  6502  output  (CROSS  can  produce  many  formats).  This  program  can 
assemble  Apple  DOS  Kermit  (APPLEK..M65).  (Actually,  there  might  be 
minor  differences  in  syntax,  like  whether  or  not  a  colon  is  required  after  a  label...) 

*  DEC- 10/20  Tools: 

The  following  tools  are  specific  to  DECsystem-10  and  DECSYSTEM-20  com¬ 
puters,  and  will  not  appear  on  distribution  tapes  for  other  kinds  of  systems,  and  will 


only  appear  at  the  end  of  DEC-10,'20  tapes  if  there  is  sufficient  room.  The  tools  files 
are  stored  separately  in  KT:,  <  KERMIT-TOOLS>  . 

The  files  MAC80.=^  M80UNV,  etc,  are  an  8080,'8085/Z80  cross  assembler  that  runs 
on  the  DEC-10  or  DEC-20;  MAC80.DOC  is  a  brief  description.  TORTUR.M80  is 
an  8080  instruction  set  "torture  test"  for  MAC80,  which  illustrates  its  features. 

ZORTUR.M80  is  a  Z80  instruction  set  torture  test.  MAC80  is  used  to  assemble 
CPM  KERMIT,  and  is  mostly  compatible  with  the  standard  CP;M  8080  assembler, 
D.R.  ASM. 

HEXIFY.*  is  a  program  for  converting  a  CP.'M  .COM  file  i  ,sl  ent  on  the 
DEC- 10  or  DEC-20  to  a  CP,'M  .HEX  file.  This  is  handy  when  binary  file  transfers 
are  failing  to  work  for  some  reason.  The  .HEX  file  can  be  LOADed  on  the  CP,'M 
system  in  the  normal  way  to  reconstruct  the  original  .COM  file.  HEXCOM.*  is  the 
inverse  of  HEXIFY,  and  provides  .HEX-to-.COM  file  conversion. 

The  files  CROSS.*  are  a  general  purpose  cross  assembler  that  runs  only  on  the 
DEC- 10  and  -20;  CROSS.DOC  is  the  manual.  CROSS  is  used  to  assemble  Apple  DOS 
and  Commodore-64  Kermits. 

WRITEL  is  a  program  to  write  ANSI  labeled  ASCII  tapes  on  the  DEC-20;  it  is 
written  in  Rutgers  Pascal,  and  requires  that  you  have  the  Rutgers  Pascal  runtime 
library  on  your  system. 

*  Finally... 

If  you  make  any  significant  modifications  to  Kermit,  fix  any  major  bugs,  or  write 
any  new  implementations  or  documentation,  please  send  them  back  to  us  onmagnetic 
tape  (or  IBM  PC  DOS  format  diskettes)  so  we  can  distribute  them  toother  Kermit  users: 


Kermit  Distribution 
Columbia  University 


a/a 


«-R193  9«4  LO-CO-GRRF  (LOU  COST  GRAPHICS):  QENERKTINO  RRPS  TO 

SUPPORT  COHHRNO  AND  CO.  .  <U>  NAVAL  POSTORAOUATE  SCHOOL 
HONTEREV  CA  R  P  SABO  ET  AL.  HAR  SB 


UNCLASSIFIED 


F/0  12/3 


NL 


Center  for  Computing  Activities 
612  West  115th  Street 
New  York,  NY  10025 

We'll  return  your  tapes  back  to  you  with  the  latest 
Kermit  distribution  (if  you  send  full-size  reels). 
Specify  format  and  tape  selection  according  the  Kermit 
order  form  (copy  in  A^-\XFLY.DOC). 


*  OTHER  WAYS  TO  GET  KERMIT  * 

To  get  Kermit  on  magnetic  tape  from  Columbia 
University,  follow  the  directions  in  the  file 
AAXFLY.DOC.  There  are  also  other  ways  to  get  Kermit: 

.  Network  Distribution: 

The  file  AANETW.HLP  contains  instructions  for 
accessing  the  Kermit  distribution  over  a  variety  of 
computer  networks  and  dialup  hosts.  AANOKS.DOC  tells  in 
detail  how  to  access  the  Kermit  archive  at  Oklahoma 
State  University. 

.  Floppy  Disk  Distribution: 

A  list  of  volunteer  individuals  and  organizations  distributing  Kermit  on 
floppy  disks  of  various  formats  can  be  found  in  the  file  AADISK.HLP.  Kermit 
diskettes  may  also  be  ordered  in  several  formats  from  Columbia  University  (see 
AAXFLY.DOC). 

.  Overseas  sources  for  Kermit  Distribution  tapes: 


UK  and  Ireland  (ANSI  and  VAX/V.VIS  BACKUP  tapes,  selected  diskettes): 


Alan  Phillips 

C  jmmunications  Group  . 

Department  of  Computing 
Computer  Building 
Lancaster  University 
Lancaster  LAI  4YW,  ENGLAND 
Phone  0524-65201  x4881 

France,  Belgium,  etc  (European  ANSI  tape  distribution  tree) 

Jean  Dutertre 

Institut  Francais  du  Petrole 

BP  311 

92506  Rued  Malmaison  Cedex,  FRANCE 
Phone  +33  I  749.02.14 

West  Germany  (ANSI  tapes): 

Dr.  Hans-Magnus  Aus 

Institut  fuer  Virologie  und  Immunbiologie 

Universitaet  Wuerzburg 

Versbacherstrasse  7 

D-8700  Wuerzburg 

WEST  GERMANY 

Phone  (931)  201-3954 

Australia: 

Rodney  Van  Cooten  (or  The  Kermit  Coordinator) 
University  Computing  Services 
University  of  Melbourne, 

Parkville, 

Victoria,  3052, 


AUSTRALIA 

E-Mail:  "munnari!murdu.oz!rvc''@SEISMO.CSS.GOV 
Japan 

Ken-ichiro  Murakami 

NTT  Basic  Research  Laboratories 

3-9-11  Midori-cho,  Musashino-shi 

Tokyo,  180 

JAPAN 

Telephone  :  0422-59-3589 

E-mail  address :  "nttlab!murakami"@ Shasta  (from 

ARPA)  or  murakami@nttlab.ntt.junet  (from  JUNET,  the 
Japanese  domestic  network.) 
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APPENDIX  D.  ACCESSING  KERMIT  FILES  VIA  COMPUTER 

NETWORKS 


This  file  is  resident  on  the  Columbia  University  Center  for  Computing  and  was  accurate 
as  of  20  Jan  S8.  It  is  up-dated  yearly. 


This  file  describes  how  to  get  Kermit  files  over  computer  networks,  including 
BITNET,  CCNET  (a  DECnet  network),  the  Internet  (Arpanet  and  the  networks 
connected  to  it),  plus  various  dialup  accesses  including  LX'CP.  You  should  also  read 
AAFILES.HLP  if  you  need  more  complete  descriptions  of  the  Kermit  files  them¬ 
selves. 


*  BITNET  from  the  Columbia  University  CUVMA  System: 

BITNET  is  a  network  of  computers,  mostly  at  universities,  connected  with  leased 
phone  lines,  using  IBM  mainframe  RSCS  protocols  (VAX  VMS  and  Unix  systems 
and  other  systems  that  can  imitate  these  protocols  are  also  on  BITNET).  BITNET 
covers  North  America,  Europe  (where  it  is  called  EARN),  and  has  recently  spread 
to  the  Far  East.  Information  about  joining  BITNET  may  be  obtained  from 
EDUCOM  Networking  Activities,  P.O.  Box  364,  Princeton,  NJ  (USA)  08540,  Phone 
609-734-1878. 

KERMSRV  at  CUVMA  is  a  file  server  for  the  BITNET  user  community  which 
accepts  commands  via  messages  or  spool  files,  and  sends  the  requested  KERMIT  files 
over  the  network.  .Most  spool  file  formats  are  accepted  including  those  used  by 
SENDFILE,  NOTE,  PUNCH,  PRINT,  CARD  DUMP,  or  DISK  DUMP  commands. 

To  learn  how  obtain  Kermit  files  from  the  Columbia  IBM  mainframes  via 
BITNET,  type  the  following  command  to  your  BITNET  host: 


V.M/C.MS:  TELL  KER.MSRV  AT  CUV.MA  HELP  (or  SMSG  RSCS 


MSG  CUVMA  KERMSRV  HELP) 

MVS/TSO/E:  TELL  KERMSRV  AT  CUVMA  HELP  (syntax  may  be 
site  dependent) 

VMS  JNET:  SEN; REM  CUVMA  KERMSRV  HELP 
UNIX  UREP:  netexec  cuvma  msg  cuvma  kermsrv  help 

The  Kennit  files  available  from  BITNET  may  be  some  days  or  weeks  behind  the 
announcements  that  appear  in  Info-Kermit  (see  below). 

Here  is  a  brief  summary  of  KERMSRV  operation;  see  the  HELP  message  for 
greater  detail; 

The  folloiving  file  request  commands  are  accepted:  SEND,  MAIL,  PUNCH, 
PRINT,  DISK,  and  CARD.  These  commands  expect  a  file  name  or  "DIR"  or  "?"  as 
an  operand.  The  DIR  operand  accepts  an  optional  file  name  also.  File  names  may 
contain  *  or  %  wildcard  characters,  but  the  filename  portion  may  not  consist  of  those 
characters  only. 

Note  that  KERMSRV  will  always  respond  with  some  message;  if  you  get  a  response 
please  do  not  resubmit  your  request.  If  your  request  was  received  as  a  spool  file,  error 
messages  are  sent  in  a  spool  file,  also. 

The  NEWS  command  returns  news  about  latest  features  and  changes  in 
KER.MSRV. 


•  BITNET  from  the  University  of  Toledo  VAX/VMS  system  UOFT02; 

The  Kermit  file  server  KERMSRV  is  not  the  same  one  as  the  one  running  at 
Columbia  —  this  is  a  VAX,  and  CUVMA  is  an  IB.M  mainframe.  The  collection  is 
maintained  by  Brian  Nelson,  author  of  PDP-11  Kermit,  mail  to  BRIAN@UOFT02  on 
BITNET. 


for  instance,  from  V.M;C.MS: 


IWBnf*WLWIUiLJ»l»U»JBJIW»llWWWW.iliU»UWJPJ  WWJWJW’Wyi!W’'Ji  V-V  wUi'’iw-.irww’iy^w»Tr»nri™ 


CP  SMSG  RSCS  MSG  UOFT02  KERMSRV  DIR 
CP  SMSG  RSCS  MSG  UOFT02  KERMSRV  SEND  Kll*.* 

(or  TELL  KERMSRV  AT  UOFT02  DIR.  etc.) 

from  VMS  Jnet:  S  SEN/REM  UOFT02  KERMSRV  SEND  Kll*.* 

Attempts  to  see  if  Kermsrv  is  'logged  in',  e.g.  SEN/COM  UOFT02  CPQ  U 
KERMSRV  or  SM  RSCS  .MSG  UOFT02  KER.MSRV  CPQ  U  KERMSRV  will  AL¬ 
WAYS  fail.  This  is  a  VMS  node  running  JNET  and  JNET  treats  server  processes 
in  a  manner  unlike  VM  does. 

•  For  all  pratical  purposes,  KERMSRV  is  always  running.  If  a  message  is  sent  to  it, 
and  for  some  reason  it's  not  there,  JNET  will  tell  you. 

Secondly,  KERMSRV  can  ONLY  respond  to  interactive  messages,  it  can  not 
process  mail. 

Additional  "satellite"  BITNET  KERMSRV  sites  may  be  established  in  the 
future  to  relieve  congestion  at  the  major  US  East  Coast  hubs.  The  need  is  particularly 
great  on  the  West  Coast  and  in  Europe.  Volunteers?  There  is  also  some  possibility 
of  converting  from  KERMSRV  to  the  more  general  and  powerful  LISTSERV  fa¬ 
cility. 

*  Internet  from  the  Columbia  University  CU20B  System: 

"Internet"  means  the  Arpanet  and  any  network  conneaed  to  it  using  TCP/IP  pro¬ 
tocols,  including  parts  of  CSnet,  many  campus  local  networks,  etc.  Access  to  the 
Columbia  Internet  Kermit  distribution  is  through  FTP,  the  Internet  File  Transfer 
Program;  consult  the  FTP  manual  for  your  own  system  in  order  to  learn  how  to  use 
your  FTP  program. 

To  get  Kermit  files  via  the  Internet,  use  FTP  (not  TELNET),  connect  to  host 
CU20B  (Internet  Host  number  ffll28. 59. 32.128“),  login  as  user  ANONY.MOUS, 
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password  KERMIT,  and  use  the  GET  or  MULTIPLE  GET  commands  to  retrieve  the 
desired  files  from  the  area  KER:,  e.g.  "GET  KER:AAAREAD.ME~,  "MULTIPLE 
GET  KERiCK*.*".  Network  users  may  consult  the  file  KER:AAVN£W.HLP  from 
time  to  time  to  see  what  new  versions  of  Kermit  have  been  installed  recently.  Sites 
whose  FTP  programs  do  not  support  the  DIRECTORY  or  MULTIPLE  GET  com¬ 
mands  may  GET  the  file  AAFILx.DIR  from  the  desired  Kermit  area  (see  below)  to 
obtain  an  up-to-date  directory  listing. 

After  logging  in  anonymously,  you  may  also  attempt  to  set  your  default  path  to 
the  desired  Kermit  directoiy,  KER;,  K2:,  K3:,  K4:,  or  K5:  (see  below),  using  FTP's 
CWD  or  CD  command.  If  you  are  prompted  for  a  password,  provide  a  null  one;  if  a 
message  advises  you  to  send  a  password,  ignore  the  message.  Since  our  network 
software  is  always  in  a  state  of  transition,  this  operation  may  or  may  not  work. 
The  following  discussion  assumes  it  does  not  work;  if  it  does,  you  can  follow  the 
same  instructions,  but  leave  off  the  prefix  KER:,  K2:,  K3:,  etc,  from  any  file  specifica¬ 
tions.  (But  if  an  operation  fails,  then  try  again  but  with  the  prefix.) 

Internet  access  to  CU20B  is  currently  unrestricted,  but  if  sufficiently  large  num¬ 
bers  of  anonymous  FTP  logins  occur  regularly  during  prime  (eastern)  time  hours  to 
interfere  with  our  own  user  community,  some  restrictions  on  anonymous  logins  will 
have  to  be  imposed. 

Those  accessing  CU20B  via  network  should  note  the  existence  of  several  Kermit  file 
areas: 

KER:  -  Popular  microcomputer,  PC,  workstation  Kermit 
implementations. 

K2:  -  Popular  mainframe  and  minicomputer  Kermit 

implementations. 

K3:  -  Less  popular  micro  &  PC  Kermits  (spillover 

from  KER;). 

K4:  -  Less  popular  mini  &  mainframe  Kermits 

(spillover  from  K2:). 

K5;  -  .Mail  archives,  full-text  user  guide,  protocol 


manual,  etc. 

KB:  -  True  binary  (executable)  files  for  selected 
implementations. 

KE:  -  "Extra",  old,  redundant,  or  "limited-edition" 

Kermit  implementations. 

KT:  -  Tools  —  cross  assemblers  and  linkers,  etc., 
mostly  to  run  on  DEC-20. 

KO:  -  Old  releases  superseded  by  new  ones. 

KER:  corresponds  to  Tape  A,  K2;  corresponds  to  Tape  B, 
to  Tape  C,  K4:  to  Tape  D,  K5:  to  Tape  E. 

These  areas  are  "logical  device  names",  which  should  be  used  rather  than  physical 
DEC-20  DEVICE:  <  DIRECTORY>  names,  which  may  change  from  time  to  time 
as  our  systems  are  rearranged.  The  logical  name  KER:  includes  all  the  others  (K2:, 
KB:,  etc)  in  its  search  path  in  the  order  listed  above,  so  to  obtain  a  single  file  you  should 
prefix  its  name  by  KER:. 

When  getting  either  single  or  multiple  files,  and  your  own  system  is  a  DEC-20, 
then  it  is  also  sufficient  to  prefix  the  file  specification  by  KER:. 

When  getting  multiple  files  from  CU20B's  FTP  server  from  non-DEC-20  systems, 
you  should  first  change  working  directory  (CWD  or  CD)  to  the  area  containing  the 
files  you  want  to  get,  e.g.  KER:  or  K2:.  If  you  don't,  then  each  file  will  be  sent  back 
to  you  with  its  fully  qualified  name  which  in  some  cases  may  be  longer  than  the 
longest  permissible  filename  on  your  system,  which  in  turn  can  cause  files  whose 
names  differ  only  in  the  last  few  characters  to  overwrite  each  other  as  they  arrive. 

Alphabetic  case  is  insignificant  in  DEC-20  file  names  (lowercase  is  mapped  to 
upper).  The  dot  separating  the  file  name  and  file  type  is  significant;  the  name  and  type 
are  separate  fields. 

File  groups  may  be  specified  in  MULTIPLE  GET  commands  using  the  following 
"wildcard"  notation: 


.  AiU*MlW  A^*d 


*  matches  any  string  of  0  or  more  characters  in  the 
current  field 

%  matches  any  single  character  in  the  current  position 


For  instance,  KER:CK*.*  matches  all  files  whose  names  start  with  CK. 
KER:CK*.%  matches  all  files  whose  names  start  with  CK  and  whose  types  are 
exactly  one  character  long  (like  KERiCKUCMD.C).  The  dot  in  DEC-20 
filenames  separates  the  filename  from  the  filetype.  KER:*  will  NOT  match  all  the  files 
in  KER:  (as  Unix  users  might  expect),  but  rather,  all  the  files  in  KER;  that  have  null 
filetx’pes.  Use  to  match  all  files. 

Each  implementation  of  Kermit  has  a  additional  prefix  imbedded  in  the  name. 
All  files  relating  to  that  implementation  have  names  that  start  with  that  prefix.  Since 
the  dot  is  significant  in  DEC-20  file  names,  the  way  to  refer  to  all  the  files  in  a 
specific  implementation  is  ’'KER:xx*.*“,  w'here  .\x  is  the  prefix,  e.g.  KER:.VIS*.*  for  all 
the  MS-DOS  Kermit  files. 

A  few  cautionary  words  about  DEC-20  logical  names:  the  search  path  is  followed 
only  so  long  as  files  are  not  found  that  match  the  given  file  specification.  This  can 
cause  some  confusion;  for  instance,  the  command  "DIRECTORY  KER:"  will  only  list 
the  files  in  the  primary  (Tape  A)  Kermit  directory,  because  when  no  file  specification 
is  given,  is  assumed,  and  all  files  in  the  primary  directory  match  so 

subsequent  directories  are  not  searched.  Similarly,  "KER;C*,*"  will  not  search  sub¬ 
sequent  directories  if  the  primary  directory  contains  any  files  that  start  with  "C".  Note 
that  "KER:*. DOC"  (whose  intention  might  be  to  refer  to  all  the  Kermit  doc¬ 
umentation  files)  would  only  find  .DOC  files  in  the  primary  Kermit  directory. 

Care  has  been  taken  to  ensure  that  files  are  arranged  so  that  if  they  are  referred 
to  by  prefix,  they  will  be  found  in  the  KER:  search  path.  For  instance,  the  C-Kermit 
files,  having  the  prefix  "CK"  will  be  found  if  referred  to  as  "KERiCK*.*",  even  though 
they  are  really  in  K2:.  However,  this  principle  applies  only  to  the  principal  directories. 
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KER:,  K2:,  K3:,  K4:,  and  K5:.  It  does  not  apply  to  KB:,  which  is  used  to  separate  bi¬ 
nary  files  from  "printable"  files.  Therefore,  KER:MS*.*  will  find  all  of  the  printable 
MS-DOS  Kermit  files,  but  will  not  find  the  .EXE  files,  which  are  in  KB:,  and  must 
be  referred  to  separately  as  KB:.MS*.*. 

Before  you  attempt  to  get  binary  files  from  the  KB:  or  KT:  direccories  with  FTP, 
you  should  know  something  about  the  way  the  DEC-20  stores  these  files: 

.  Native  DEC- 10  or  DEC-20  programs  are  stored  in  36- 
bit  binary  format,  and  will  be  transferred  correctly  to 
other  DEC- 10  or -20  systems  without  doing  anything 
special.  They  probably  can't  be  transferred  to  other 
kinds  of  systems,  except  maybe  36-bit  Honeywells  or 
Sperrys. 

.  "Foreign"  8-bit  binary  files  are  stored  four  8-bit 
bvtes  left  justified  within  the  36-bit  word.  You  can 
get  these  files  from  another  DEC- 10  or  -20  without 
doing  anything  special,  but  to  get  them  from  some  other 
kind  of  system,  you  have  to  give  FTP  the  command  "TYPE 
L  8",  "type  binary",  and/or  "TENEX"  first. 

If  you  are  originating  your  FTP  requests  from  a  DEC-20  or  TENEX  system,  no 
special  precautions  are  necessary  regarding  file  types  or  name  conversion.  If  you  are 
coming  from  another  kind  of  system,  you  will  probably  find  that  the  files  you  obtain 
are  stored  with  names  contrary  to  your  system's  naming  conventions.  For  instance, 
if  you  tell  Unix  FTP  to  "mget  kerck*.*",  you  may  find  the  files  stored  in  your  directory 
with  names  like 


PK:  <  KERMIT>  CKAAAA.HLP.2 
when  you  really  want  stored  with  names  like 


ckaaaa.hlp 


A  special  program  is  available  to  Unix  sites  for  doing  the  appropriate  file  name 
conversions,  called  xxu.c  ("get  kenxxu.c").  The  recommended  procedure  for 
FTP'ing  files  to  a  Unix  system  is  to  make  a  new  directory  for  them,  cd  to  it,  then  get 
the  files,  including  ker.xxu.c,  then  build  xxu.c  (just  type  "cc  -o  xxu  xxu.c";  the  result 
should  run  under  any  version  of  Unix),  then  do  "xxu  *"  to  convert  the  names.  See 
the  XXU.C  source  comments  for  details. 


USING  KERMIT  WITH  AN  INTERNET  TERMINAL  ACCESS  CONTROLLER 
(TAC). 

(Thanks  to  Edward  Haines  <  haines@BBNCCI.ARPA>  for  these  hints) 

There  are  some  conditions  that  must  be  met  to  successfully  use  Kermit  on  a  per¬ 
sonal  computer  through  a  TAC. 

Flow  Control 

The  buffer  size  for  a  terminal  port  on  a  TAC  is  typically  about  64  bytes.  (The  size 
is  a  configuration  parameter.)  Since  the  default  packet  size  in  Kermit  is  usually  80-96 
bytes  it  is  quite  likely  that  buffer  overflow  will  occur. 

Some  possible  solutions: 

1.  Enable  flow  control  in  Kermit  on  the  PC  and  on  the 

TAC.  Many  PC  versions  of  Kermit  implement  XON/XOFF  flow 

control,  including  the  MS-DOS  version  for  the  IBM  PC. 

To  enable  flow  control  on  the  TAC  issue  the  TAC  commands 

@  Flow  Input  Start 

@Flow  Output  Start 

These  are  usually  abbreviated  @f  i  s  and  (gf  o  s.  Note 


that  flow  control  is  not  compatible  with  binary  mode 
(except  see  note  below). 

2.  Make  the  packet  size  on  the  PC  Kermit  small  enough 
to  not  overflow  the  TAC  bufler,  e.g.  60  bytes.  The 
normal  command  is  “set  receive  packet-length  60",  which 
you  give  to  the  Kermit  that  is  about  to  receive  files. 

3.  Increase  the  buflfer  size  in  the  TAC.  This  is  not 
usually  practical  and  won't  be  considered  further. 

TAC  Intercept  Character. 

The  default  TAC  intercept  character  is  the  AT-sign.  The  AT-  sign  is  also  required 
by  the  Kermit  Protocol,  so  unless  you  take  one  of  the  measures  listed  below,  Kermit 
packets  won't  get  through  the  TAC. 

Solutions 

1.  Have  the  PC  Kermit  automatically  double  AT-signs  on 
output.  This  is  probably  the  best  solution  in  general. 

This  feature  is  available  on  some  PC  implementations  of 
Kermit.  It  is  not  yet  available  on  the  .MS-DOS  version. 
fflEd.  -  it's  available  in  CP/M-80  Kermit  4.0x.“ 

2.  Change  the  TAC  Intercept  character  with  the  command 
@Intercept  < decimal  ASCII  value> 

For  instance,  “@I  6“  sets  the  intercept  character  to  Ctrl-F. 

3.  Put  the  TAC  into  Binary  mode.  This  has  the  side 
effect  of  disabling  the  Intercept  character.  It  also 


will  allow  you  to  transfer  binary  files  without  special 
encoding.  The  TAG  can  be  put  into  Binary  mode  with  the 
commands 


a 

I 
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@ Binary  Input  Start  (@b  i  s) 

@  Binary  Output  Start  (@b  o  s) 

Some  host  systems  aiiow  you  to  engage  the  binary  mode 
from  the  host.  DEC-20  Kermit  has  a  command  for  this. 

There  are  several  problems  with  binary  mode: 

Some  host  systems  don't  support  it. 

You  lose  the  ability  to  control  the  TAG  from  the  PC. 

You  lose  the  ability  to  do  XON/XOFF  flow  control. 

Binary  Files 

It  is  sometimes  desireable  to  be  able  to  transmit  an  8-bit  binary  file  between  a  host 
and  a  PC.  The  TAC  (which  implements  the  DDN  Telnet  Protocol)  normally  provides 
just  a  7-bit  ASCII  path. 

Solutions 
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1.  Enable  binary  mode  (if  possible)  as  described 
above. 

2.  Enable  8th  bit  prefixing  (if  available)  in  both 
Kermits.  (This  is  usually  done  by  enabling  parity  via 
Kermit's  SET  PARITY  command.) 

Notes 

1.  You  will  probably  get  the  best 
throughput  for  ASCII  files  by  keeping  the 


packet  size  as  large  as  possible  and  using 
flow  control. 


2.  There  is  not  much  advantage  in 
increasing  the  baud  rate  between  the  PC  and 
the  TAC  beyond  1200  baud  because  of  the 
relatively  long  turnaround  time  for  the 
acknowledgement  packet. 

3.  You  may  have  problems  when  going  through 
satellite  hops  or  multiple  gateways  due  to  the 
occasional  very  long  delays.  This  may  result 

in  Kermit  giving  up.  The  problem  can  be 
circumvented  to  by  increasing  the  timeout 
interval;  many  Kermits  have  commands  to  allow 
this:  SET  SEND/RECEIVE  TIMEOUT. 

4.  Only  the  first  letter  of  a  TAC  command 
is  required. 

5.  It  is  possible  to  set  binary  mode  in 
only  one  direction.  For  example  you  can  set 
Inbound  binary  and  retain  input  flow  control 
(XON7XOFF  flow  is  in  the  opposite  direction). 
You  probably  don't  need  outbound  (input  to  the 
PC)  flow  control  when  using  the  Kermit 
protocol. 


•  CCnet: 

CCnet  is  a  DECnet  network  of  cooperating  universities.  Kermit  flies  may  be 
accessed  using  XFT  to  CU20B::KER:.\xx.yy7,  where  .xxx.jyy  is  the  name  of  the  file 
or  file  group  you  want  to  get.  Some  sites  (regarded  as  "secure")  may  specify 


/USER:ANONYMOUS,  but  most  sites  will  have  to  supply  a  valid  CU20B  user  ID  and 
password.  If  your  system  is  on  CCnet  and  you  cannot  get  anonymous  NFT  access  to 
CU20B,  you'll  have  to  ask  your  system  manager  to  get  the  files  for  you.  Read  the 
Internet  section  above  about  device,  directory,  and  wildcard  conventions. 


*  United  Kingdom  (Information  from  Alan  Phillips,  Lancaster  University); 

Though  there  is  a  central  registry  of  UK  site  names  known  as  \RS,  it  is  not  auto¬ 
matic  and  many  people  have  no  access  to  it,  so  include  the  actual  DTE  addresses  if  you 
can.  Details  for  mail: 

JANET  network  :  SYSKERMIT  @  UK.AC. LANCS. VAX  1 
(actual  address  is 
0000 10404000.  FTP.MAI  L) 

PSS  network  :  SYSKERMIT(^234252400101. 

000010404000.FTP.MAIL  or  to 
the  JANET  address  via  the 
Rutherford  gateway 

BITNET  :  SYSKERMIT%LANCS.VAXl  @  UK.AC 

ARPA  :  SYSKER.MIT%LANCS.VAX1  @  CS.UCL. 

AC.UK 

We  do  not  support  file  transfer  to  BITNET/ARPA  -  users  have  to  log  in  as  a  ter¬ 
minal  and  use  KERMIT.  Over  PSS  and  JANET  we  support  ftp  using  Blue  Book 
protocol:  For  details  pull  file  00INFO.TXT  from  user  KERMIT,  quoting  password 
KERMIT.  FTP  address  is 

JANET  :  0000 10404000. FTP 


PSS 


:  234252400101.000010404000.  FTP' 


Or  people  can  just  mail  me  and  I'll  send  details.  Afraid  we  have  no  equivalent  of  the 
BITNET  KER.MSRV  server  or  Arpa  anonymous  ftp  over  here.  Dial-up  ports  are 
available;  I'll  send  details  to  anyone  wanting  them. 

While  we're  very  happy  for  anyone  to  ftp  from  us  or  log  in  to  us  from  anywhere, 
and  we'll  put  anyone  on  the  mailing  list,  we  can't  handle  letters  and  phone  calls  from 
outside  the  UK  and  Eire.  Nor  can  we  send  files  to  people  who  can't  ftp  them. 

*  Mail: 

There  is  a  network  mailing  list  for  Kermit  information;  it  is  available  to  users 
of  BITNET  and  the  Internet  and  most  networks  that  are  connected  to  them, 
inclusing  CSnet,  Usenet,  Mailnet,  CCnet,  and  others.  To  get  on  the  mailing  list,  send 
mail: 

-  From  -  -  To  - 

BITNET  KERMIT@CUVMA 

CCNET  Info-Kermit-Request@CU20B 

Arpa  Internet  Info-Kermit- 

Request@CU20B.COLUMBIA.EDU 
CSNET  Info-Kermit-Request%CU20B.COLUMBIA. 

EDU@CSNET-RELAY 

Mailnet  Info-Kermit-Request%CU20B.COLUMBIA. 

EDU@MIT-MULTICS 
U  senet  ...!uunet!columbia!cu20b!info- 

kermit-request 

DEC  Easynet  DECWRL::"Info-Kermit-Request@CU20B. 

COLUMBIA^DU' 

UK  JANET  SYSKERMIT@UK.AC.LANCS.VAXl 

If  your  system  won't  let  you  use  long  names  or  names  with  dashes  in  mail  ad¬ 
dresses,  then  just  substitute  "KERMIT"  for  "Info- Kermit- Request". 
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Also,  as  of  December  1988,  the  Kermit  mailing  list  is  available  via  BITNET 
LISTSERV.  This  is  a  facility  that  lets  you  subscribe  and  unsubscribe  yourself  To 
subscribe  via  LISTSERV,  send  an  electronic  mail  message  to  L1STSERV@CUVMA. 
The  body  of  the  message  should  contain  the  line: 


SUBSCRIBE  I-KERMIT  your  personal  name 


For  instance 


SUBSCRIBE  I-KERMIT  Fred  C.  Dobbs 


To  remove  yourself  from  the  list,  send  the  following  message: 


UNSUBSCRIBE  I-KERMIT 


To  learn  more  about  LISTSERV,  send  it  a  message  “HELP"  or  "INFO  ?". 


Dialup: 


Several  publicly  accessible  dialup  Kermit  collections  are  available  in  the  US: 


1.  The  University  of  Toledo  allows  limited  dialup  access  to  its  UOFT02  VAX/VMS 


system: 


(419)  537-4411 
Service  class  VX785A 


User:  KERMIT 


Password:  KERMIT 


Source  and  hex  files  are  in  KER:,  binaries  are  in  KERBIN: 


2.  Oklahoma  State  University: 


'V 


UUCP  and  Kermit  access  to  the  complete  Kermit  distribution  is  available  from  the 
Department  of  Computing  and  Information  Sciences.  Oklahoma  State  University, 
Stillwater,  Oklahoma.  The  procedures  are  somewhat  complicated,  and  are  described 
in  a  separate  file,  AANOKS.DOC. 
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APPENDIX  E.  KERMIT  USER'S  GUIDE 


This  is  a  step-by-step  guide  for  using  KERMIT  to  access  the  NFS  mainframe  from 
a  Heath/Zenith  100  or  89  microcomputer.  The  procedures  were  developed  by  the  long 
proven  scientific  trial  and  error  method  and  some  very  old  notes  from  a  1984  file  on  the 
mainframe  titled  ''Z100h89  fullscrn  B".  If  you  happen  upon  improvements  and/or  cor¬ 
rections  to  this  guide,  please  provide  them  and  any  other  comments  to  the  computer 
department  so  they  can  be  added.  This  and  the  other  KERMIT  text  files  were  written 
by  R.  G.  Bishop  in  .A.pril  1987  at  the  request  of  the  NFS  Computer  Center. 

A.  KERMIT  IN  GENERAL 

There  are  many  help  files  and  documents  available  to  help  you  become  familiar  with 
KERMIT  commands  and  attributes.  These  help  files  and  KERMIT  User  Guides  can 
be  accessed  through  the  BITNET,  Defense  Data  Network  (DDN)  and  the  mainframe. 
Rather  than  attempt  to  duplicate  them  here,  you  should  access  them  yourself  if  you  are 
in  need  of  further  information.  This  instruction  sheet  will  provide  all  the  information 
you  need  to  access  the  mainframe  and  from  there  you  can  learn  more. 

1.  Versions  of  KERMIT 

There  are  more  than  200  versions  of  KERMIT  circulating  around  for  over  50 
specific  machines  and  more  than  5  for  MS-DOS  in  general.  This  instruction  set  is  writ¬ 
ten  for  KERMIT  version  2.27  which  is  available  from  the  computer  department  with 
several  special  changes  set  up  to  communicate  with  the  mainframe  using  a  Z- 100/89. 

2.  Required  Files 

You  will  need  both  MSZ100.EXE  and  .MEKER.M1T.INI  on  your  disk  to  use 
these  procedures.  The  original  disk  for  this  instruction  sheet  includes  KERMIT.DOC 
and  READ..ME. 

B.  BRIEF  OVERVIEW  OF  PROCEDURES 

1.  Dial  into  the  Mainframe  accessing  SIM3278. 

2.  Choose  the  VT100-in-the-VT52-mode  terminal  emulator  package. 

3.  Set  up  your  Z- 100/89  in  the  alternate  keypad  mode. 

4.  Log  on  exactly  as  you  would  from  a  terminal  at  school. 

5.  Decide  whether  to  transfer  files  or  do  screen  editing. 

6.  Use  substitute  keys  to  imitate  the  FF  keys. 


1.  The  Details 

a.  Loading  KERMlTfor  MS-DOS 

NOTE:  For  this  instruction  sheet  ''<CR>"  means  carrage  return  key, 
<esc>  means  escape  key  and  <ctrl>  means  control  key.  Under  most 
circumstsnces  you  will  use  the  <ctrl>  key  simultaneously  with  another  key. 

Put  the  disk  containing  KERMIT  in  the  active  drive  and  enter: 


MSZlOO  <  CR>  This  loads  KER.VIIT  and  the  system 
will  respond  with  with: 

Heath-Zenith  Z-100  Kermit-.MS  V2.27 


Type  ?  for  help 


KERM1T-MS> 


When  the  prompt  appears  enter: 


DO  IBM  <  CR  >  This  will  set  up  the  communications 
protocall  to  the  correct  values  and 
return  the  prompt,  KER.M1T-MS>  . 


b.  Set  Up  Modem 


Now  turn  your  modem  on  and  enter: 


Connect  or  C  <  CR  >  This  begins  the  connect  sequence. 
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Next  "dial"  the  mainframe.  For  an  auto-diai  modem  enter: 


ATD6462709  <  CR  >  This  will  call-up  the  computer  for 

1200  or  300  baud  operation. 


NOTE:  If  you  do  not  have  an  auto-dial  modem  follow  your  modem's 
instructions  for  call  or  dial-up. 

The  system  will  respond  with: 

CONNECT  1200 

VM,  370  ONLINE-  -PRESS  BREAK  KEY  TO  BEGIN  SESSION 
!  Enter  <CR> 


The  system  will  respond  with: 

Enter  one  of  the  following  commands: 

LOGON  userid  (Example:  LOGON  V.VIUSERl) 

DIAL  userid  (Example:  DIAL  VMUSER2) 

•MSG  userid  message  (Example:  MSG  VMUSER2  GOOD  .MORNING) 
LOGOFF 


This  is  the  mainframe  dot  prompt. 


m_mT  GO  FURTHER  UHTIL  YOU  READ  THE  NEXT  SECTION 
DQ  NOT  GO  FURTHER  UNTIL  YOU  READ  THE  NEXT  SECTION 
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c.  What  do  you  want  to  do  this  session  ? 

At  this  point  you  must  make  a  decision  about  what  you  want  to  do.  If  you 
wish  to  transfer  files,  see  TRANSFERRING  FILES,  if  you  wish  to  do  full  screen  editing 
(same  as  being  on  a  terminal  at  school)  continue  with  the  section,  SCREEN  WORK. 

(1)  Screen  work.  You  have  dialed  up  the  Mainframe  and  must  now  get 
to  the  period  prompt.  DON'T  log  on  with  your  user  id  yet.  Instead  enter  the  following: 


DIAL  SIM3278  <  CR>  This  will  cormect  you  to  the 
mainframe's  communications 
protocall  software. 

The  system  will  respond  with; 

DIALED  TO  SIM3278  091  S  I  M  3  2  7  8  (C)  Simware  Inc.  1984  VERSION  3.4 

Please  Enter  Your  Terminal  ID;  '?'  for  menu,  'L'  for  LOGOFF 


When  asked  what  type  of  terminal  you  are,  enter: 

9  <  CR  >  You  may  look  at  the  menu  if  you 

want  by  entering  ?  You  enter  9  to 
choose  the  DEC  VTIOO  in  the  VT52 
mode,  and  press  RETURN. 

The  screen  will  clear  and  the  large  NPS  logo  will  appear  like  the  one  on  the  3270  con¬ 
sole's  at  school. 


Now  you  must  enter  a  sequence  which  will  turn  your  keypad  on  and  place  your  Z-100 
keypad  in  the  Alternate  character  mode.  Enter: 

Note  the  small  (lower  case)  x. 

Place  the  H-89  in  the  shifted 


<  esc>  x7  <  CR> 
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keypad  mode  by  pressing  <  ESC>  x6. 
(Note  the  lower  case  x.) 


=  =  >  The  Z-100  has  separate  arrow  keys  on  the  keypad.  Use 
these  to  move  the  cursor  around. 

=  =  >  On  the  H-89,  the  shifted  keypad  mode  allows  the  arrow 
keys  to  work  as  is.  To  access  the  rest  of  the  functions, 
you  must  press  the  shift  key  with  the  keypad  key. 


The  system  will  respond  with: 


Enter  one  of  the  following  commands: 


LOGON  userid  (Example:  LOGON  VMUSERl) 

DIAL  userid  (Example:  DIAL  VMUSER2) 

MSG  userid  message  (Example:  MSG  VMUSER2  GOOD  MORNING) 
LOGOFF 

This  is  the  mainframe  dot  prompt. 

Logon  as  you  would  normally  do  at  a  terminal  by  entering: 

logon  XXXXP  <  CR  >  Where  XXXX  is  your  user  Number. 

Your  password  WILL  show  up  on  the 
srceen,  but  no  matter.  This  should 
also  execute  your  exec  files  as 
normal  after  logon.  If  not  press 
return  again. 

The  system  will  respond  with  the  LOGON  message  and  leave  you  with  the  system 
prompt  "dot". 


DIAL  userid 


'  <•'  *a*.>A*.H*  *t'.*a*  < A* i4t* A* A* 


There  is  an  attachment  to  this  instruction  which  shows  the  key  equivalents  for  the  Z-100. 
In  all  cases  you  must  enter  the  keys  (in  sequence  if  more  than  one)  and  end  with  a  car¬ 
riage  return  <  CR> . 

(2)  Transferring  files.  To  transfer  files  you  must  'set  the  mainframe  up' 
to  send  or  receive  a  file  first .  Then  "drop"  down  to  your  KERMIT  and  do  the  trans¬ 
ferring.  To  drop  down,  you  must  enter  control,  right  bracket,  <  ctrl>  simultaneously, 
and  then  enter  the  appropriate  send  or  receive  on  your  KERMIT. 


Logon  as  you  would  normally  do  at  a  terminal  by  entering: 

logon  XXXXP  <  CR  >  Where  XXXX  is  your  user  Number. 

Your  password  WILL  show  up  on  the 
srceen,  but  no  matter.  This  should 
also  execute  your  exec  files  as 
normal  after  logon.  If  not  press 
return  again. 

The  system  will  respond  with  the  LOGON  message  and  leave  you  with  the  system 
prompt  "dot". 


Now  link  to  the  mainframe's  KERMIT  by  entering: 

Linkto  KERMIT  <  CR  >  The  system  will  respond  with: 

Linked  to  user  kermit  disk  191... 
and  will  give  you  the  KERMIT-CMS> 
prompt.  There  is  no  help  file 
available,  but  ?  displays  the 
KER.MIT  options  available.  This  may 
again  execute  your  exec  files. 
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If  you  have  forgotten  which  file  you  wanted  to  send  or  just  want  to  look,  you  can  see 
your  filelist  (directoiy)  by  entering  the  follownng  sequence; 

QUIT  or  Q  <  CR  >  Quits  kermit  and  returns  to  ems  at 
which  time  you  can  enter; 

listflle  <  CR  >  Which  will  display  your  director>’. 

to  get  back  to  kermit  enter; 

KERMIT  <  CR  >  The  system  will  display  KERMIT-CMS. 

To  send  a  file  from  the  main  frame  to  home  computer  enter; 
send  filename  file  type  file  mode  <  CR  > 

<ctrl>-l  <CR>  Drops  to  your  KERMIT*MS>  prompt. 

receive  filename. extension  <  CR  >  ? 


At  this  time  you  will  see  a  file  transfer  status  menu.  This  will  give  you  a  menu  which 
shows  how  the  transfer  is  working. When  the  transfer  is  complete  it  will  tell  you  (along 
with  some  other  ?  facts  about  that  file  ? 


d.  Logging  off 


You  logoff  at  the  end  of  your  session  as  normal  and  then  enter: 


I 


<ctrl>-C]  <CR> 


The  control,  <  Ctrl  > ,  and  right 
bracket  “  must  be  done  at  the  same 
time  (simultameously)  and  then  the 
C  and  <  CR>  . 


Now  you  are  at  the  KERMIT-MS>  prompt.  Enter; 


QUIT  or  Q  <  CR  >  This  will  bring  you  back  to  the 
operating  system. 

2.  Tips  for  300  baud  users 

Since  300  baud  can  be  very  slow,  try  to  minimize  those  actions  which  call  for  a 
complete  screen  update.  Some  examples; 

1.  In  XEDIT,  do  most  of  your  corrections  on  the  whole  page  {using  the  arrow  keys) 
before  you  move  Up  or  Dowm.  Then  move  a  whole  page  if  possible. 

2.  In  the  Input  mode  in  XEDIT,  use  the  NEWLINE  function  (ESC  <  cr>  )  to  move 
the  cursor  down  to  column  one  of  the  next  line  instead  of  pressing  <cr>  alone. 
RETURN  <  cr>  causes  the  whole  screen  to  be  updated  as  the  lines  you've  entered 
so  far,  are  moved  up  above  the  action.  Once  you  have  entered  seven  or  so  lines, 
then  press  <  cr>  to  accept  the  lines  and  update  the  screen. 

3.  Z- 100/ IBM  3270  keyboard  equivalence 

Use  Figure  11  to  imitate  the  various  function  keys  normally  found  on  the  3270 
terminals  connected  to  the  IB.M  at  NFS. 


--M  *ji  ■•ji  **  *>  '  > 


HOME/ SCHOOL  KEY  EQUIVALENCES 


Here  are  some  key  equivalences: 


VT-52  (term  9) 

H89  (KP=Keypad)  Z-100 

IBM  3270 

KEYS 

CODES 

SENT 

REMARKS 

==> 

ARROW  KEYS  <  =  ■ 

<-- 

<-- 

<-- 

<ESC> 

D 

shift  6 

shift  6 

shift  6 

<ESC> 

A 

V 

V 

V 

<ESC> 

B 

--> 

--> 

<ESC> 

C 

■ 

>  FUNCTION 

keys  <  • 

BLUE<cr> 

F6<cr> 

PFl 

<ESC> 

P 

RED<cr> 

F7<cr> 

PF2 

<ESC> 

Q 

WHITE<cr> 

F8<cr> 

PF3 

<ESC> 

R 

Fl<cr> 

Fl<cr> 

PF4 

<ESC> 

S 

shft  KP  7<cr> 

KP  7<cr> 

PF5 

<ESC> 

? 

w 

shft  KP  8<cr> 

KP  8<cr> 

PF6 

<ESC> 

? 

X 

shft  KP  9<cr> 

KP  9<cr> 

PF7 

<ESC> 

? 

y 

ESC  ?  m  <cr> 

KP  -<cr> 

PF8 

<ESC> 

? 

m 

shft  KP  4<cr> 

KP  4<cr> 

PF9 

<ESC> 

? 

t 

shft  KP  5<cr> 

KP  5<cr> 

PFIO 

<ESC> 

7 

u 

shft  KP  6<cr> 

KP  6<cr> 

PFll 

<ESC> 

? 

V 

? 

? 

PF12 

? 

shft  KP  l<cr> 

KP  l<cr> 

PAl 

<ESC> 

? 

q 

Goes  to  CP 

shft  KP  2<cr> 

KP  2<cr> 

PA2 

<ESC> 

? 

r 

? 

shft  KP  3<cr> 

KP  3<cr> 

#GOTO(SIM) 

<ESC> 

7 

s 

1  „ 

ESC<cr> 

ESC<cr> 

Newline 

<ESC> 

3270  key 

shft  ENTER<cr> 

ENTER<cr> 

Alt  Clear 

<ESC> 

7 

M 

also  PA2 

CTRL  a 

CTRL  a 

Insert  char 

<CTRL 

a> 

CTRL  b 

CTRL  b 

Delete  char 

<CTRL 

b> 

once  for  each 

char  to  delete 

Figure  11.  ZlOO/IBM  3270  Key  Equivalence:  NOTE:  Some  of  the  function  keys 
have  not  been  located,  If  you  find  errors  or  more  definitions,  let  us 
know. 


4.  The  Quick'N'Dirty  Version 

After  doing  this  several  times  you  will  get  to  the  point  when  you  do  not  need 
all  this  information  to  operate  in  the  KERMIT  environment.  Figure  12  fits  neatly  on 
a  three  by  five  card  which  can  be  tucked  into  the  jacket  of  your  KER.MIT  disk. 


"  MAINFRAME 'N  KERMIT  " 


MSZlOO  <CR> 

DO  IBM  <CR> 

modem  on  Connect  <CR>  ATD6462709 

—  TO  TX  FILES . SCREEN  WORK - 

LOGON  XXXXP  <CR>  DIAL  SIM3278  <CR> 

LINKTO  KERMIT  <CR>  <esc>x7  <CR> 

Q  <CR>,  LISTFILE  <CR>  LOGON  XXXXP  <CR> 
KERMIT  <CR> 

t  mainframe  firsti 


LOGOFF  <CR> 


LOGOFF  <CR> 

<ctrl>-C  <CR>,  QUIT 


APPENDIX  F.  TEKTRONIX  TERMINAL  EMULATOR 


The  following  programs  were  developed  on  the  Z-100  using  Z-BASIC  under 
MS-DOS  version  2.  The  programs  used  to  generate  the  pictures  in  Appendix  I  were 
compiled  by  the  Z-BASIC  compiler. 

A.  TEKTRONIX  GRAPHICS  TERMINAL  EMULATION  PROGRAM 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 
13 
20 
21 
22 
23 

30 

31 

32 

33 

34 

40 

41 

42 

43 

44 

50 

51 

52 

53 

54 

55 
60 

61 

62 

63 

64 

65 
70 
80 


'  TECKTRONIX  4006  /  4010  GRAPHICS  TERMINAL  EMULATOR 
’  FOR  THE  Z-100  UNDER  MS-DOS  MODIFIED  FOR  THE  DDN 

t 

'  ORIGINALLY  SUGGESTED  BY  GLEN  ROBERTS  APRIL  28,  1984 
'  UNDER  Z-DOS  TO  MAKE  THE  Z-100  COMPUTER  EMULATE  A 
’  TEKTRONIX  PROTOCOL  GRAPHICS  TERMINAL 
'  THIS  VERSION  WILL  RUN  UNDER  MS-DOS  2  AND  HIGHER 
'  MODIFIED  BY  R.  SABO  AND  R.  BISHOP  JAN  1988 

I 

DEFINT  A-Z:DIM  P!(224):DEF  SEG  =  &HE000 
'  CHARACTER  CONSTANTS 


CTRLC=3:  FF=12:  X0N=17:  X0FF=19:  ESC=27:  GS=29:  US=31:  SPACE=32 


'  INITIALIZE  VARIABLES 

I 

FALSE=0:  TRUE=N0T  FALSE;  GRMODE=FALSE:  HAVL0Y=FALSE:  A=0 

I 

'  THE  FOLLOWING  COMMUNICATION  PROTOCOL  CONSTANTS  MAY  BE 
'  MODIFIED  AS  NEEDED  FOR  THE  APPLICATION  YOU  ARE  UNDER 

t 

BAUD$="1200":  PARITY$="N":  BITS$="8'' 


'  HOME  THE  CURSOR  AND  CLEAR  THE  SCREEN 
'  TURN  KEY  ASSIGNMENTS  OFF 

I 

SCREEN  0,0:  KEY  OFF:  CLS 

'  INITIALIZE  THE  ARRAY  TO  INDEX  THE  BYTES 
'  FOR  BIT  IMAGE  PRINTING  (NOT  USED  IN  THIS  VERSION) 


R=0:F0R  J=0  TO  392  STEP  16:  FOR  1=0  TO  8: P!  (R)=( I+J)*128: 
R=R+1:NEXT  I:  NEXT  J 

t 

'  ASSIGN  KEY  INTERRUPTS  TO  THE 
'  APPROPRIATE  SUBROUTINES 

'  THIS  AREA  IS  WHERE  FURTHER  WORK  CAN  TAKE  PLACE 

t 

KEY(l)  ON:  ON  KEY(l)  GOSUB  530 
KEY(2)  ON:  ON  KEY(2)  GOSUB  560 


90  KEYO)  ON:  ON  KEY(3)  GOSUB  590 
100  KEYf4)  ON:  ON  KEY(4)  GOSUB  620 
110  KEY(5)  ON:  ON  KEY(5)  GOSUB  740 
120  KEY(6)  ON: ON  KEY(6)  GOSUB  470 
130  KEY(7)  ON:  ON  KEY(7)  GOSUB  760 
140  KEY(8)  ON: ON  KEY(8)  GOSUB  780 

150  KEY(9)  ON:  ON  KEY(9)  GOSUB  800 

151  ’ 

152  '  PRINT  25th  LINE  AND  TITLE  HEADING  ON  SCREEN 

153  ' 

160  GOSUB  620 

170  PRINT  "TEKTRONIX  4006  /  4010  GRAPHICS  TERMINAL  EMULATOR" 
180  PRINT 

190  PRINT  "BAUD  :  ";:  SCREEN  ,1: PRINT  BAUD$; :  SCREEN  ,0 

200  PRINT  "  PARITY  :  ";: SCREEN  ,1:  PRINT  PARITY$;  :  SCREEN  ,0 

210  PRINT  "  BITS  :  SCREEN  ,1:  PRINT  BITS$; :  SCREEN  ,0 


212  '  OPEN  SERIAL  COMM  CHANNEL  AS  FILE  iH 

213  '  OPEN  SCREEN  OUTPUT  AS  FILE  #2 

214  ' 

218  ’ 

220  OPEN  "COMl:  "+EAUD$+","+PARITY$+","+BITS$  AS  #1 
230  OPEN  "SCRN: "  FOR  OUTPUT  AS  n 

240  PAUSE=FALSE 

241  ' 

242  '  THIS  IS  THE  MAIN  EXECUTION  LOOP 

243  '  FIRST  CHECK  FOR  CHARACTERS  IN  THE  COMM  BUFFER 

244  '  IF  NONE  THEN  JUMP  TO  SEE  IF  SYSTEM  IS  WAITING 

245  '  FOR  AN  X-ON  ALSO  CHECK  COMM  BUFFER  TO  SEE  IF  FULL 


250  IF  L0C(1)=0  THEN  430 

251  ' 

252  '  HANDLE  HANDSHAKING  IF  COMM  BUFFER  IS  ALMOST  FULL  THEN 

253  '  SEND  AN  XOFF  TO  THE  REMOTE  SYSTEM  TO  STOP  DATA 

254  '  TRANSMISSION  AND  SET  PAUSE  TO  TRUE  TO  INDICATE  THAT 

255  '  THE  REMOTE  SYSTEM  IS  WAITING  FOR  AN  X-ON 

256  ' 

260  IF  (LOC(1)>60)  AND  NOT  PAUSE  THEN  PAUSE=TRUE:  PRINT  #1 ,CHR$(XOFF); 

261  ' 

262  ’  SAVE  THE  LAST  RECIEVED  CHARACTER,  THE  READ  A  NEW  CHARACTER  FROM 

263  '  THE  COMM  BUFFER 

264  '  (STRIP  THE  8TH  BIT  IF  ANY) 

265  ' 

270  LASTA=A:  A=ASC(INPUT$(1,#1))  AND  127 

271  ' 

272  '  IF  THE  CHAR  IS  A  CONTROL  CHAR  OR  IF  WE  ARE 


272  '  IF  THE  CHAR  IS  A  CONTROL  CHAR  OR  IF  WE  ARE 

273  '  NOT  IN  THE  GRAPHICS  MODE  THEN  JUMP 

274  ' 

280  IF  A<SPACE  THEN  390 
290  IF  NOT  GRMODE  GOTO  420 

292  '  HANDLE  THE  GRAPHICS  CHAR 

293  '  PUT  HIGH  TWO  BITS  INTO  MODE  VARIABLE 

294  '  THEN  PUT  LOW  FIVE  BITS  INTO  THE  BITS  VARIABLE 


300  MODE=A  32;BITS=A  AND  31 
310  ON  MODE  GOTO  320,340,380 


311 

312 

313 

314 

315 

316 

317 

318 
320 

330 

331 

332 

333 

334 

335 

336 

337 

338 
340 
350 
360 

370 

371 

372 

373 

374 

375 

376 

380 

381 

382 

383 

384 

385 

386 

387 

390 

391 

392 

393 

394 

400 

401 

402 

403 

404 

407 

408 

409 

410 

411 

412 

413 

414 

415 


I  FOR  THE  CASE  WHERE  MODE  =01  (HIGH  X  OR  HIGH  Y) 

’  IF  WE  ALREADY  HAVE  A  LOW  Y  THEN  THIS 
'  MUST  BE  A  HIGH  X,  ELSE  IT  MUST  BE  A  HIGH  Y. 

'  SHIFT  IT  FIVE  BITS  SO  THAT  THE  LOW  VALUE 
’  MAY  BE  ADDED  LATER. 

I 

IF  HAVLOY  THEN  HIX=BITS*32  ELSE  HIY=BITS*32 
GOTO  430 

t 

I  MODE  =  10  (LOW  X) 

'  THE  HIGH  AND  LOW  DATA  IS  COMPLETE.  START  DRAWING  THE 
'  VECTOR  ON  THE  SCREEN.  THIS  IS  DONE  USING  THE  Z-BASIC 
’  "DRAW"  STATEME.NT.  SCALING  IS  5/8  X  AND  7/24  Y 
'  IF  THE  VECTOR  IS  INVISIBLE  ADD  "B"  TO  BLANK  IT. 

I 

Y=15*(780-(L0Y+HIY))  52:  X=5*(BITS+HIX)  8 
L$="M"+MID$ ( STR$ ( X) , 2 ) +" , "+MID$( STR$( Y) , 2 ) 

IF  BLANK  THEN  L$="B"+L$ 

DRAW  L$:  BLANK  =  FALSE:  HAVLOY=FALSE:  GOTO  430 

I  FOR  THE  CASE  WHERE  MODE  =  11  (LOW  Y) 

'  SAVE  LOW  Y  VALUE  AND  REMMEMBER  THAT  WE  HAVE 
'  RECEIVED  A  LOW  Y 

t 

LOY=BITS:  HAVLOY=TRUE: GOTO  430 

I 

'  HANDLE  COTROL  CHARACTERS  HERE 
’  IF  A  GROUP  SEPARATOR  (GS)  THEN  ENTER  THE 
•  GRAPHICS  MODE  AND  REMMEMBER  THAT  THE  NEXT  VECTOR 
'  WILL  BE  INVISIBLE  (YOU  ALWAYS  START  WITH  AN  INVISABLE 
'  VECTOR  SO  YOU  CAN  POSITION  TO  THE  CORRECT  STARTING  PLACE) 

IF  A=GS  THEN  GRMODE=TRUE:  BLANK=TRUE:  CLS:  GOTO  430 

I 

'  IF  A  UNIT  SEPERATOR  (US)  THEN 
'  EXIT  THE  GRAPHICS  MODE 

t 

IF  A=US  THEN  GRMODE=FALSE:  LOCATE  25,1:  GOTO  430 


'  IF  FORM  FEED  (FF)  AND  THE  LAST  WAS  (ESC),  THEN  CLEAR  SCREEN 
I  AND  THE  25TH  LINE,  THEN  EXIT  GRAPHICS  MODE 

IF  A=FF  AND  LASTA=ESC  THEN  CLS;  LOCATE  25,1: 

PRINT  SPACE$(80);:GRMODE=FALSE:GOTO  430 

'  THE  CHAR  IS  EITHER  A  NORMAL  CONTROL  CHAR 
’  OR  WE  AKC  NOT  IN  GRAPHICS  MODE 
'  JUST  SEND  IT  TO  THE  SCREEN 
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420  PRINT  j'/2,CHR$(A); 

421  ' 

422  '  IF  X-OFF  HAS  BEEN  SENT  SEE  IF  BUFFER  IS  ALMOST  EMPTY 

423  '  IF  IT  IS,  SEND  AN  X-ON 

424  ' 

430  IF  (LOC(1)<10)  AND  PAUSE  THEN  PAUSE=FALSE:  PRINT  #l,CHR$(XON); 

431  ' 

432  '  NOW  POLL  THE  KEYBOARD.  IF  A  KEY  HAS  BEEN  HIT 

433  '  THEN  TRANSMIT  THAT  CHARACTER  TO  THE  REMOTE  SYSTEM 

434  '  AND  GO  BACK  TO  THE  TOP  OF  THE  LOOP 

435  ' 

440  A$=INKEYS 

450  IF  A$<>""  THEN  PRINT  #1,A$; 

460  GOTO  250 

461  ' 

462  '  SUB  TO  PRINT  SCREEN  USING  BIT  IMAGE  GRAPHICS  ON  C.  ITOH  PROWRITER 

463  ’  OTEHR  SIMILAR  PRINTERS. 

464  ' 

470  BEEP 
^.^0  ' 

490  ’ 

500  ' 

510  ' 

520  RETURN 

522  ’ 

523  '  ROUTINE  TO  NAME  AND  SAVE  SCREEN  PICTURES 

524  ' 

530  LOCATE  1 , 1:  INPUT"PICTURE  NAME:  ”,SCNM$ 

531  ' 

532  ' 

535  BSAVE  SCNM$ ,0 ,50256! 

536  GOSUB  620 
540  BEEP 

550  RETURN 

554  ' 

555  '  THE  SPACES  HERE  CAN  BE  USED  TO  PROGRAM  THE  "FUTURE" 

556  '  THINGS  REMOVED  FOR  OUT  PROOF  OF  CONCEPT  VERSION 

557  '  WHEN  CALLED  THEY  WILL  JUST  BEEP  FOR  NOW 

558  ' 

560  BEEP 


570  BEEP 
580  RETURN 
590  BEEP 
600  BEEP 

610  RETURN 

611  ' 

612 

613 

614 

615  ' 

620  CLS:  LOCATE  25,1 
630  PRINT  "  1"; : SCREEN 
640  PRINT  "  2"; : SCREEN 
650  PRINT  "  3";; SCREEN 
660  PRINT  "  4";: SCREEN 
670  PRINT  "  5":; SCREEN 


'  SUB-ROUTINE  TO  CLEAR  SCREEN  AND  PRINT  A  REMINDER  PROMPT 
'  ON  THE  25TH  LINE.  THE  PROMPT  SHOWS  THE  FUNCTION  KEYS 
’  AND  THEIR  ASSIGNED  STSTUS 


,1: PRINT  "SAVE 
,1: PRINT  "FUTURE' 
,1:  PRINT  "FUTURE 
,1: PRINT  "CLS 
,1: PRINT  "QUIT 


SCREEN 

SCREEN 

SCREEN 

SCREEN 

SCREEN 


,0 

,0 

,0 

,0 

,0 


SCREEN  ,0 
SCREEN  ,0 
SCREEN  ,0 


680  PRINT  "  6";:  SCREEN  .1:  PRINT  "FUTURE"; :  SCREEN  ,0 
690  PRINT  "  7";; SCREEN  ,1:  PRINT  "  C  SCREEN  ,0 

700  PRINT  "  8";:  SCREEN  ,1:  PRINT  "XOFF  SCREEN  ,0 

710  PRINT  "  9";:  SCREEN  ,1:  PRINT  "XON  SCREEN  ,0 

720  LOCATE  1,1 

730  RETURN 

731  ' 

732  ’  CLOSE  ROUTINE 

733  ' 

740  CLOSE:  KEY  OFF:  CLS 

750  STOP 

751  ' 

752  '  ROUTINES  NEEDED  TO  SEND  CONTROL  CHARS  NORMALLY 

753  '  TRAPPED  IN  ZBASIC  INTEREPRETED  VERSIONS.  MAY  NOT 

754  '  BE  NEEDED  IN  THE  COMPILED  VERSION 

755  ' 

760  PRINT  #1,CKR$(CTRLC); 

770  RETURN 

780  PRINT  #1,CHR$(X0FF); 

790  RETURN 

800  PRINT  //1,CHR$(X0N); 

810  RETURN 


B.  PLAYBACK  PROGRAM  LISTING 

While  this  is  not  very  elegant  it  does  serve  its  purpose.  Further  work  on  this  pro¬ 
gram  could  do  much  to  improve  its  functions. 


1  ’  THIS  IS  THE  LO-CO-GRAF  "PLAY  BACK"  PROGRAM 

2  ’  IT  PROMPTS  FOR  THE  NAME  OF  THE  PICTURE  TO 

3  '  GET  FROM  A  FILE  AND  THEN  PAINTS  IT  ON  THE  SCREEN 

4  '  AT  THAT  POINT,  YOU  CAN  PRINT  IT  TO  PAPER  WITH  THE 

5  '  SCREEN  DUMP  PROGRAM 

6  ' 

10  ' 

20  CLS 

30  DEF  SEG=&HE000 

31  ' 

33  '  LINES  40  THRU  70  GET  THE  NAME  OF  THE  FILE  DATA 

34  '  TO  BE  DISPLAYED,  PLAY  BACK  THE  PICTURE  AND 

35  '  RINGS  A  BELL  TO  TELL  YOU  IT  IS  COMPLETE. 

36  ' 

40  INPUT  "NAME  OF  PICTURE  FILE  TO  LOAD  "; FILENAMES 
50  CLS 

60  BLOAD  FILENAMES, 0 

70  BEEP 

71  LOCATE  25,1:  PRINT  "ENTER  ANY  KEY  TO  QUIT  OR" 

72  LOCATE  25,31:  PRINT  "  PRESS  SHIFT  F-12  TO  PRINT" 

90  AS=INKEYS:  IF  AS=""  THEN  90 

100  STOP 


I 


-M 

% 

•i' 


wTi 


'  IT  PROMPTS  FOR  THE  NAME  OF  THE  PICTURE  TO 
'  GET  FROM  A  FILE  AND  THEN  PAINTS  IT  ON  THE  SCREEN 
'  AT  THAT  POINT,  YOU  CAN  PRINT  IT  TO  PAPER  WITH  THE 
'  SCREEN  DUMP  PROGRAM 


APPENDIX  G.  SCREEN  DUMP  ROUTINE 


This  documentation  file  is  available  on  the  distribution  disk  for  the  screen  dump 
routine  titled: 


SCDMP.COM  -  Version  3.4  -  15-Oct-85 


SCREEN  DUMP  UTILITY  FOR  H  Z- 100 
(for  U.  S.  Govenunent  use  only) 


A.  INTRODUCTION 

SCDMP  is  a  utility  that  allows  reproduction  of  a  complete  video  screen  on  a 
dot  matrix  printer,  including  both  text  and  graphics,  without  having  to  exit  the 
current  program.  The  SCDMP  program  may  be  loaded  manually  (by  entering 
SCDMP  <  cr> )  or  automatically,  via 'autoexec.bat',  into  memory  at  the  beginning 
of  a  session  where  it  remains  resident  until  needed.  To  print  a  desired  stationary 
screen,  simply  press  <SHIFT-F12>,  which  generates  an  interrupt-5  and  activates 
the  screen  dump. 

The  program  allows  a  choice  of  which  color  bank  of  video  RA.M  is  dumped  (if 
the  user  has  all  btinks  of  color  RAM  in  hisZlOO).  The  number  of  VRA.M  banks 
installed  in  your  computer  is  determined  by  SCDMP  upon  initial  load.  For  the 
color  version,  entering  a  <B>  for  blue,  <R>  for  red,  <G>  for  green,  or  <A> 
for  all  banks  immediately  after  the  <  SHIFT-F12>  will  select  the  VRAM  bank  to  be 
printed.  If  no  character  is  entered,  <A>I1  banks  is  the  default.  If  only  one  bank 
of  color  RAM  is  installed,  only  the  green  bank  can  be  dumped. 

The  program  also  allows  multiple  density  printing  for  some  printers.  Entering 
an  <H>  immediately  after  the  <SHIFT-F12>  or  color  selection  would  cause  the 
printer  to  use  a  higher  density  mode  for  printing.  The  default  density  is  normal 
or  standard  density.  The  program  also  allows  a  choice  of  printing  the  twenty-fifth 
line,  if  displayed.  Entering  a  <D>  immediately  after  the  <SHIFT-F12>  or 
color  or  density  selection  will  cause  SCDMP  to  dump  the  25th  line  if  it  is  dis¬ 
played. 

The  program  also  allows  the  default  values  for  the  switch  settings  to  be 
changed  at  any  time  after  the  program  is  loaded.  Entering  a  <C>  after  any  of  the 
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above  settings  will  cause  a  change  in  the  default  values  only.  They  will  be  reset 
as  requested  and  a  beep  will  sound  to  confirm  the  reset.  The  screen  will  not  be 
dumped. 

Approximately  three  seconds  is  allowed  after  initiation  of  SCDMP  before  the 
default  values  are  assumed.  The  default  values  can  also  be  changed  at  the  time  of 
initial  load  of  screen  dump,  by  entering  the  appropriate  changes  via  the  command  line, 
such  as 

SCDMP  .xyz<cr> 

where  x  =  <  B  >  lue,  <  R  >  ed,  <  G  >  reen,  or  <  A  >  11  banks  default 
y  =  <  N  >  ormal  or  <  H  >  igh  density  default 
z  =  <  D  >  ump  25th  line,  if  displayed 

This  will  allow  SCDMP  to  be  setup  with  the  proper  defaults  for  your  application. 
Activation  would  not  require  the  switches  after  the  <SH1FT-F12>.  This 
makes  calling  SCD.MP  from  within  another  program  more  versatile. 

In  the  event  that  it  is  necessary  to  stop  the  printing  of  a  screen,  entering 
<  ESC  >  during  printing  of  the  screen  will  abort  the  dump  (a  'Q'  can  also  be  used  if 
called  from  within  another  program). 

SCD.MP  can  be  aaivated  from  within  many  popular  programs  such  as  .Multiplan, 
ZBASIC,  Graftalk,  ZDS  Business  Graphics,  Z-Chart,  Doodler,  CHART,  and  others. 
SCDMP  will  not  work  with  Lotus  123  or  Watchword  as  these  programs  bypass  the 
MSDOS  'get  character'  call.  SCD.MP  conforms  to  the  operational  standard'  created 
by  Zenith's  PSC.ASM,  except  that  both  graphics  and  text  are  reproduced. 

B.  REQUIREMENTS 

This  program  requires  the  ZDOS/.MSDOS  operating  system  (Version  1.25  or 
higher)  on  a  H/Z-IOO  computer.  The  printers  currently  supported  for  U.  S.  Gov¬ 
ernment  use  are  the  Epson  .MX/RX,  FX  Series  with  Graftrax,  the  Okidata  .MicroLine 
83A,  and  Zenith/ M PI  99/150  Series. 

C.  DISTRIBUTION  FILES 

The  following  files  are  included  on  the  distribution  disks  of  SCDMP.  Documenta¬ 
tion  for  operation  and  modification  of  the  programs  is  also  included. 


SCDMP  .DOC  Screen  Dump  information 
SCD.VIPEPS.COM  Version  for  Epson  .MX  Series 
SCDMPOK2.COM  Version  for  Okidata  .Microline  Series 


CDMPVIPI  .COM  Version  for  Zenith/ .MPI  99/150  Series 


SCD.MP  .BAT  Batch  file  for  auto  load  of  SCDMP. CO.M 
(rename  the  appropriate  program  to 
SCDMP.COM) 


D.  INSTALLING  THE  PROGRAM 

Choose  the  version  of  the  screen  dump  required  by  the  specific  printer  ap¬ 
plication.  Rename  the  version  to  SCD.MP.COM  as  follows: 


REN  SCDMPxxx.COM  =  SCDMP.COM 


Load  the  screen  dump  program  into  resident  memory  as  follows: 


SCD.MP  <cr>  or  SCD.MP  xyz<  cr> 


A  sign-on  message  will  display  the  version  number  and  the  printer  application 
with  instructions  for  dumping  the  screen.  Screen  dump  instructions  will  be  similar 
to  the  following; 


To  dump  screen,  type:  <  SHIFT-F12>  fflW“fflX“fflY“fflZ“ 


fflW  =  <  G >  reen  or  <  B >  lue  or  <  R>  ed  or  <  A>  11  banks" 

SIX  =  <  N  >  ormal  or  <  H  >  igh  density" 

filY  =  <  D>  ump  25th  line" 

fiiZ  =  <  C  >  hange  default  settings" 
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defaults:  VRAM  bank  =  A  print  density  =  X 


To  abort  dump  during  printing,  type:  <  ESC> 


Typing  of  <  SHIFT-F12> -W--X--Y--Z-  will  suspend  execution  of  the  current 
program,  dump  the  screen  to  the  printer,  and  return  to  the  current  program  with  no 


cnanse. 


NOTE:  Versions  of  SCDMP  are  available  for 


other  printers.  Contact  Mr.  Les  Bordelon  at 
(714)  793-S853  for  additional  information. 


Program  Author: 
Leslie  L.  Bordelon 


1453  Femwood  Drive 


Redlands,  CA  92374 
714-793-8853 


Additional  Credits  to: 


Digital  Information  Systems  (Original  Graphics  Routines) 
Zenith  Data  Systems  (Interrupt-5  Handling  from  PSC.COM) 


ip 


APPENDIX  H.  ACCESSING  THE  BRIEFING  AID  SYSTEM 


This  file  is  on  the  DDN  viewer  system  for  accessing  the  Briefmg  Aid  System. 
It  explains  how  to  configure  the  information  file  which  must  be  placed  in  your  DDN 
directory.  The  file  is  titled: 

<  LEVEL2>  L'SING-TAC-TER\IINALS.DOC.3 

Using  a  Graphics  Terminal  on  the  TAC 
Revised  27-Sep-83 

Before  attempting  to  use  a  Graphics  Terminal  on  a  TAC,  verify  that  port  to 
be  used  is  set  in  “Wild  Mode"  and  “Quiet  Mode".  These  settings  must  be  authorized 
by  the  site  liaison  and  executed  by  the  Network  Operations  Center.  Only  if  "Wild 
Mode"  is  enabled  will  the  Graphics  System  be  able  to  connect  to  the  TAC;  if  not 
enabled,  the  Graphics  System  will  simply  minute  during  Initialization  and  then  return 
an  error  (subcode  =  64009). 

"Quiet  Mode"  suppresses  all  messages  on  the  TAC  port.  This  means  no  "TCP 
Trying...",  "Open",  or  "Closed"  messages  should  appear  when  attempting  to  use  the 
Graphics  Terminal  as  a  regular  terminal. 

Once  you  have  determined  that  the  port  is  correctly  tailored,  issue  the  fol¬ 
lowing  commands  to  the  TAC  from  your  Graphics  Terminal: 

@  RESET  <  return  > 

(Theage  similar  to:) 

(^PROTOCOL  TCP  <  return > 

(This  command  should  no  longer  be  required) 

@ECHO  HALFDUPLEX 

(Instructs  the  T.AC  not  to  echo  characters) 


Use  another  terminal  to  login  and  run  your  program  using  the  string 
"DEVICE  =  (T,RAND'TAC-xxx)"  in  the  INIT  command,  "xxx"  should  be  the  TCP 
port  number,  in  octal,  of  the  graphics  terminal  on  the  T.AC.  TCP  port  numbers  may 
be  calculated  from  the  terminal  port  number  in  the  herald  after  the  REilET  command 
(in  the  above  case,  the  terminnumber  is  3). 


Terminal  Port  Number 

1 

o 

3 

4 

5 

6 


TCP  Port  Number  (Octal) 
427 
1027 
1427 
2027 
2427 
3027 


p  256  *  p  +  23 

(expressed  in  octal) 

For  example,  to  run  your  program  on  a  Tektronix  connected  to  terminal  port  4  on 
CCA-TAC  use  the  initialization  string: 

BACKEND  =  (TEKTRONTX),DEVICE  =  iT,CCA-TAC-2027) 

When  you're  done  using  the  Graphics  Terminal,  you  may  have  reset  Echoing  on 
the  TAC  porCHO  REMOTE 


APPEiNDIX  I.  SAMPLE  MAPS  GENERATED  BY  LO-CO-GRAF  AND 

THE  BRIEFING  AID  SYSTEM 


The  following  cartographic  products  were  displayed  by  the  LO-CO-GRAF  terminal 
emulation  sy’stem  using  the  Briefing  Aid  System  for  map  generation.  The  maps  w’ere 
transferred  from  USC-ISI  via  DON  to  a  Z-100  microcomputer  and  then  printed  on  an 
Epson-equivalent  dot  matrix  printer  using  a  screen  dump  routine.  Examples  of  maps 
and  charts  printed  under  these  options  are  listed  in  Table  3. 


Table  3.  GUIDE  TO  LO-CO-GRAF  MAPS 


Map  Title 

Page 

Airroutes.GPX 

37 

North-West  Europe 

38 

Atlantic  Ocean  and  Caribbean  Sea 

125 

•Mediterranean  Sea 

126 

Tyrrhenian  Sea 

127 

North  Sea 

128 

English  Channel  with  political  boundaries 

129 

Straits  of  Hormuz 

130 

Ethiopian  Conflict 

131 

FJWWWRW  I 


^ji 


APPENDIX  J.  SAMPLE  MAPS  GENERATED  BY  DISSPLA 

The  generated  maps  for  the  major  systems  described  in  this  thesis  follow.  The  dif¬ 
ferences  in  line  thickness  is  a  function  of  the  printer  being  used  and  does  not  reflect  on 
the  cartographic  resolution.  These  maps  were  generated  by  DISSPLA  version  10.2 
World  Coast  Utilities  Option  and  printed  by  an  IBM  3800  laser  printer.  Examples  of 
maps  and  charts  printed  under  these  options  are  listed  in  Table  4. 

Table  4.  GUIDE  TO  DISSPLA  GENERATED  MAPS _ 

■Map  Title _  Page 

Washington,  DC _  18 

North-West  Europe _  39 

World  .Mercator  Projection _  133 

Cape  Canaveral/ Kennedy  Space  Center _  134 

Carribean  Operating  Area _  135 

Mediterranean  Operating  Area _ 136 _ 

Japan  and  the  Kurile  Islands _  137 

Northern  Flank  of  NATO _ 1_38 _ 

Nonh  and  South  America  139 


">  '1.V  i.-.  '■ 
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Figure  26.  North  and  South  America 
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